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Preface  to  the  Second  Edition 

This  new  edition  of  the  Ada  Adoption  Handbook:  A  Program  Manager’s  Guide  extensively  updates  the 
original  1987  SEI  report  [109].  Since  that  time,  over  1,500  copies  of  the  first  edition  have  been  distributed 
by  the  SEI,  and  almost  500  copies  by  NTIS  and  DTIC,  making  this  one  of  the  most-frequently  requested 
documents  in  DTIC  holdings.  It  is  impossible  to  estimate  the  number  of  copies  of  the  first  edition  that  have 
been  reproduced  and  distributed  by  readers. 

In  the  intenrening  years,  the  technology  supporting  Ada  has  improved  dramatically,  Ada  has  come  into 
wider  use,  and  the  mandate  to  use  Ada  for  defense  systems  has  been  strengthened.  This  second  edition 
is  motivated  by  the  need  to  update  the  earlier  version  to  address  current  issues  regarding  the  use  of  Ada. 
In  1987,  the  issues  revolved  around  the  technical  adequacy  of  Ada,  its  tools,  and  its  initial  adoption  and 
use;  in  1992,  the  compilers  and  tools  have  greatly  improved  and  a  much  larger  usage  base  has  provided 
experience  and  results  to  better  understand  the  issues  of  adopting  Ada  and  managing  Ada  projects. 
Today,  the  issues  emphasize  the  management  aspects  of  using  Ada  in  the  development  of  software¬ 
intensive  systems. 

The  intent  of  this  second  ed'ttion  is  to  help  program  managers  become  better  consumers  of  Ada  products 
and  systems  by  understanding: 

•  the  management,  personnel,  and  technical  implicatk>ns  of  Ada 

•  Ada's  role  in  the  software  development  process 

Understanding  these  topics  will  aid  managers  in  moving  their  organizations  toward  widespread  use  of 
Ada  in  building  and  maintaining  software-intensive  systems. 
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Ada  Adoption  Handbook:  A  Program  Manager’s  Guide 

Abstract.  The  Ada  Adoption  Handbook  provides  program  managers  with  information  about 
how  best  to  tap  Ada’s  strengths  and  manage  the  transition  to  fully  using  this  software  tech¬ 
nology.  Although  the  issues  are  complex,  they  are  not  all  unique  to  Ada.  Indeed,  many  of  the 
issues  addressed  in  this  handbook  must  be  addressed  when  developing  any  software-intensive 
system  in  any  programming  language.  The  handbook  addresses  the  advaritages  and  risks  in 
adopting  Ada.  Significant  emphasis  has  been  placed  on  providing  information  and  suggesting 
methods  that  will  help  program  and  project  managers  succeed  in  using  Ada  across  a  broad 
range  of  application  domains. 

The  handbook  focuses  on  the  following  topics:  Ada's  goals  and  benefits;  program  management 
issues;  implications  for  education  aixJ  training;  software  tools  with  emphasis  on  compiler  valida¬ 
tion  and  quality  issues;  the  state  of  Ada  technology  as  it  relates  to  system  design  and  im¬ 
plementation;  arxl  the  perxiir^  update  of  the  Ada  language  standard  (Ada  9X). 


1.  Introduction 

1.1.  Purpose  and  Scope 

Ada  is  a  pmgramming  language  tor  developing  software,  including  information  systems, 
mission-critical,  and  embedded  applications.  Ibis  handbook  presents  program  managers  with 
information  to  make  effective  use  of  Ada. 

This  han(ftx>ok^  provides  program  managers  with  information  about  how  best  to  tap  Ada's  strengths  and 
incorporate  this  software  technology  into  their  programs.  Although  the  issues  are  sometimes  complex, 
adopting  Ada  can  be  managed.  Similar  issues  must  be  addressed  when  using  any  programming  lan¬ 
guage  for  building  sophisticated  software-intensive  systems.  Although  Ada’s  origins  were  strongly  In¬ 
fluenced  by  the  needs  of  the  defense  mission-critical  computing  community,  the  language  design  team 
placed  emphasis  on  supporting  modem  software  engineering  practices;  the  result  is  a  language  with  wide 
applicability  in  developing  well-engineered,  quality  software. 

This  handbook  addresses  the  advantages  and  risks  inherent  in  Ada  adoption.  Significant  emphasis  has 
been  placed  on; 

•  providing  information  and  suggesting  methods  that  will  help  program  and  project  managers 
succeed  in  using  Ada,  and 

•  presenting  that  information  in  an  objective  manner. 

This  handbook  should  not  be  construed  as  supplanting  DoD  policy. 

This  handbook  has  been  written  for  use  across  many  application  domains  and  covers  a  large  number  of 
fundamental  Ada  issues.  However,  it  does  rrof  address  issues  that  are  unique  to  individual  application 
domains  (for  example,  ground-based  command  and  control  systems  or  embedded  avionics)  or  specific 
programs. 


'This  handbook  is  one  of  kwo  volumes  of  the  ^cia  Adoption  Handbook  senes  produced  by  the  SEI,  which  also  includes  the  Ada 
Adoption  Handbook:  Compiler  Evaluation  and  Selection  (226).  The  Compiler  Evahmtion  and  Selecflbn  volume  provides  a  substan¬ 
tive  overview  of  the  issues  confronted  by  software  managers  and  lead  technical  personnel  tasked  with  evaluating  and  selecting  Ada 
compilers. 
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1.2.  Handbook  Overview 


This  section  describes  the  organization  of  this  handbook. 

This  handbook  is  organized  as  stand-alone  chapters  that  address  program  managers’  questions  about 

Ada  and  provide  plans  for  adopting  and  inserting  Ada  into  an  organization.  The  chapters  are; 

1 .  Introduction:  This  chapter.  Includes  the  purpose  of  this  handbook  and  provides  guidance 
for  using  the  handbook. 

2.  Program  Manager  Considerations;  Commonly  asked  questions,  succinct  answers,  and, 
where  needed,  pointers  to  rrrare  detailed  information.  Topics  include  general  information, 
technical,  management,  cost,  and  program  control  issues.  This  chapter  can  be  used  (among 
other  purposes)  as  an  executive  summary  for  the  rest  of  the  handbook  and  to  review  par¬ 
ticular  points. 

3.  The  Need  for  Ada;  An  ovenriew  of  Ada’s  goals  and  benefits,  and  policies  for  Ada’s  use. 

4.  Management:  An  overall  view  of  the  impact  of  Ada  on  the  management  process  and 
management  factors  relating  to  the  transition  to  Ada  use. 

5.  Learning  Ada:  Training  implications  and  education  issues. 

6.  Software  Production  Technology:  An  overall  view  of  software  tools,  with  particular  em¬ 
phasis  on  compiler  validation  and  compiler  quality  issues. 

7.  Ada  Applicability:  An  overall  view  of  the  current  state  of  Ada  technology,  and  discussion  of 
system  engineering  issues. 

8.  System  Design  and  implementation  Issues: 

•  Designing  for  Portability  and  Reuse:  Discusses  how  Ada  facilitates  developing 
portable  and  reusable  software. 

•  Using  Ada  with  Other  Standards  and  Protocols:  Using  Ada  interfaces  to  other 
systems  and  standards  for  successful  integration  of  Ada  software  in  overall  systems 
environments. 

•  Using  Special-Purpose  Languages:  The  application  of  special-purpose  lan¬ 
guages  such  as  ATLAS,  simulation  programming  languages,  LISP  (or  other  artificial 
intelligence  languages),  and  fourth-generation  languages. 

•  Mixing  Ada  with  Other  Languages:  Possible  approaches  for  dealing  with  existing 
operational  systems,  including  language  translation  and  hybrid  (mixed  language) 
systems. 

9.  From  Ada  83  to  Ada  9X:  A  discussion  of  the  Ada  9X  Project,  the  evolving  Ada  9X  language 
standard,  and  the  expected  impact  on  present  and  future  programs  of  moving  from  the 
present  language  standard  (Ada  83^)  to  the  revised  standard  (Ada  9X). 

The  following  appendices  are  also  included: 

A.  Ada  Information:  Recommended  readings  and  resources  for  individuals  looking  for  fun¬ 
damental  Ada  information. 

B.  Ada  Working  Groups  and  Resources:  Information  about  organizations  involved  in  Ada 
issues,  standardization,  and  policy. 


^Although  the  International  Standards  Organization  (ISO)  standard  was  approved  in  1987,  the  existing  Ada  language  is  often 
called  Ada  83,  at  least  in  the  United  States,  as  the  American  National  Standards  Institute  (ANSI)  standard  {13|  was  approved  in 
1983. 
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1.3.  Tips  for  Readers 

This  section  highlights  techniques  for  quick  and  efficient  use  of  this  handbook. 

In  addition  to  the  question-and-answer  approach  used  in  Chapter  2,  several  other  techniques  have  been 
used  to  help  the  reader  make  maximum  use  of  this  handbook: 

•  Summaries;  A  summary  begins  each  major  section.  Each  summary  is  centered  and  italicized 
for  easy  identification. 

•  Bold  and  Bullets;  Major  points  are  emphasized  by  using  bold  headings  within  bulleted  lists. 

The  major  points  are  then  followed  by  detailed  discussion. 

•  Action  Plans;  Actions  to  facilitate  the  adoption  of  Ada  are  presented  at  the  end  of  some  major 
sections. 

•  Reading  Lists;  Detailed  additional  material  on  specific  topics  are  identified  at  the  end  of  some 
chapters. 

•  Software  Development  Tutorial:  The  terms  and  concepts  of  software  development  discussed 
in  this  handbook  are  defined  in  Section  6.1 .  Readers  unfamiliar  with  these  terms  and  concepts 
are  strongly  encouraged  to  read  that  section  first. 

The  following  topics  are  not  covered  in  this  handbook: 

•  Details  of  the  Ada  language  or  software  engineering  concepts. 

•  Details  of  particular  methodologies  such  as  structured  analysis,  object-oriented  design  (OOD)  or 
any  specific  OOD  techniques  such  as  hierarchical  object-oriented  design  (HOOD);  other  design 
or  analysis  methods  such  as  process  abstraction  method  (PAMELA),  Ada-based  Design  Ap¬ 
proach  for  Real-Time  Systems  (ADARTS),  or  rate  monotonic  analysis  (RMA). 


1.4.  Changes  in  Version  2 

This  version  of  the  handbook  has  been  extensively  revised  to  reflect  the  current  state  of  Ada 
usage.  This  section  summarizes  those  revisions. 

Although  the  Ada  language  definition  hs^  remained  constant  since  its  standardization  in  1983,  much  has 
changed  with  respect  to  the  Ada  milieu  since  the  previous  version  of  this  handbook — the  number  and 
quality  of  compilers  have  increased,  and  many  additional  efforts  have  used  Ada  successfully  in  the  inter¬ 
vening  years.  This  edition  has  been  revised  and  expanded  to  incorporate  some  of  the  lessons  learned 
since  1987.  Major  changes  include: 

•  Chapters  2  Program  Manager  Considerations  and  Chapters  3  The  Need  for  Ada  have  been 
updated. 

•  Chapter  4  Management  has  been  added. 

•  Chapter  5  Learning  Ada:  Training  Implications  has  been  extensively  revised. 

•  Chapter  7  Ada  Applicability  has  been  updated. 

•  Chapters  System  Design  and  Implementation  Issues  has  added  material  about  Ada  bindings 
to  other  standards  and  protocols,  as  well  as  material  on  portability. 

•  Chapter  9  From  Ada  83  to  Ada  9X  has  been  added  to  introduce  the  Ada  9X  efforts  and  the 
enhanced  capabilities  that  are  defined  in  the  evolving  Ada  9X  starxlard. 
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•  For  More  Information  sections  containing  reading  lists  have  been  added  to  several  chapters. 

•  Appendix  A  Ada  Information  has  been  added  to  provide  the  reader  with  additional  sources  of 
information  about  Ada. 

•  Appendix  B  Ada  Working  Groups  and  Resources  has  also  been  updated. 

•  An  acronym  list  has  been  added  to  aid  the  reader. 

•  The  reference  list  has  been  extensively  updated. 

•  Appendices  on  Ada  textbooks,  Ada  compilers,  and  Ada  programs  have  been  deleted  because 
more  current  information  can  be  obtained  from  the  Ada  information  Clearinghouse  or  the 
Language  Control  Facility  Ada-JOVIAL  Newsletter.  See  Appendix  B  for  contact  information. 
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2.  Program  Manager  Considerations 

Ada  offers  considerable  advantages  over  other  languages  used  for  software  development. 

Because  Ada  technology  and  Its  use  are  still  evolving,  program  managers  may  have  questions 
about  this  techrmlogy.  Questions  fall  Into  severed  categories:  general,  costs,  technical  issues, 
program  management,  and  getting  help. 

This  handbook  provides  program  managers  with  information  to  make  well-informed  decisions  about  using 
Ada.  Some  frequently  asked  questions  and  answers  are  presented  on  the  following  pages.  Where 
needed,  pointers  to  supplemental  information  and  appropriate  actions  are  provided. 


2.1 .  General 

The  following  questions  are  covered  in  this  section: 

•  What  is  Ada  and  why  was  it  developed? 

•  For  what  application  domains  should  Ada  be  used? 

•  What  is  DoD  policy  on  Ada  use? 

•  What  are  the  advantages  of  using  Ada? 

•  What  are  some  of  the  Inhibitors  to  adopting  Ada? 

•  Who  manages  Ada? 

•  What  is  the  Ada  9X  Project?  What  will  its  impact  be? 

Question:  What  is  Ada  and  why  was  it  developed? 

Answer:  Software  development  and  post-deployment  support  are  increasingly  recognized  as  serious 
problems  for  software-intensive  system  development.  Ada,  the  computer  programming  language 
(ANSI/MIL-STD-1815A  [13])  developed  under  the  sponsorship  of  the  Department  of  Defense  (DoD), 
addresses  these  problems  by: 

•  reducing  the  need  for  multiple  programming  languages,  so  effort  can  be  focused  on  support¬ 
ing  fewer  languages  and  making  one  language  work  well,  and 

•  enabling  the  use  of  modem  software  development  methods,  thereby  reducing  the  costs  and 
risks  of  software  development  and  facilitating  in^ved  maintenance  during  post-deployment 
support. 

Ada  is  a  United  States,  North  Atlantic  Treaty  Organization  (NATO),  international,  and  DoD  standard 
programming  language.  The  Ada  language  standard  does  not  itself  define  software  development 
methods  and  processes  for  using  that  programming  language. 

See:  Sections  3.1, 3.2. 

Question:  For  what  application  domains  should  Ada  be  used? 

Answer:  Ada  is  a  programming  language  designed  to  meet  the  needs  of  developing  and  maintaining 
large,  complex  software  systems.  Although  Ada  was  originally  desigrted  to  support  real-time  arxf 
embedded  systems,  usage  has  shown  that  Ada  is  applicable  to  many  other  application  domains,  such 
as  large-scale  information  systems,  scientific  computation,  and  systems  programming.  Ada  has  been 
successfully  used  in  applications  that  vary  widely  in  size  and  application  domains  in  both  the  public 
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and  private  sectors.^  In  domains  such  as  scientific  computing  or  management  information  systems 
(MIS)  applications,  a  number  of  existing  utiiities  (numeric  libraries,  report  generation  tools,  etc.)  may 
have  to  be  re-aeated  or  interfaced  with  to  achieve  with  Ada  the  same  degree  of  usefulness  that  they 
had  with  other  languages. 

The  development  of  the  Ada  language  focused  programming  deveiopment  methods  and  tools  on  a 
single  language  that  supports  modem  software  engineering  techniques.  These  techniques  are  ap¬ 
plicable  regardless  of  the  application  domain. 


See:  Sections  3.3, 4.1 .1 .2, 7.1 . 


Question:  What  is  DoD  policy  on  Ada  use? 

Answer:  By  legislation  and  policy,  Ada  has  been  defined  as  the  required  language  for  developing 
Department  of  Defense  software  development,  where  cost  effective.  Ada's  role  as  the  single,  com¬ 
mon,  high-order  programming  language  is  a  major  step  forward  in  addressing  DoD  software  develop¬ 
ment  problems.  Current  DoD  policy  regarding  the  use  of  Ada  is  described  in  DoD  Directive  3405.1 
[77]  and  DoD  Instruction  5000.2  [79].  This  latter  instruction  [79],  which  implements  the  legislation 
mandating  Ada's  use  within  the  DoD,  requires  that  Ada  be  the  only  programming  language  used  In 
new  defense  systems  and  major  software  upgrades  (the  redesign  or  additton  of  more  than  one-third  of 
the  software)  of  existing  systems. 

This  policy  places  the  responsibility  of  applying  the  Ada  mandate  on  the  individual  program 
manager  —  to  comply,  managers  will  have  to  be  aware  of  Issues  such  as  appropriate  hardware  and 
software  selection  (to  ensure  that  validated  Ada  implementations  are  selected),  implications  of  life- 
cycle  costs,  and  the  size  or  magnitude  of  planned  ^sterns  or  upgrades. 

Each  DoD  component  has  designated  a  senior  official  as  the  Software  Executive  Official,  who  will 
serve  as  a  focal  point  for  Ada  usage  within  its  organizatton. 

See:  Sections  3.2, 6, 7,  Appendix  B.4. 

Question:  What  are  the  advantages  of  using  Ada? 

Answer:  Ada's  expected  overall  advantage  can  be  summarized  as  increased  quality  per  dollar  spent. 
Specifically,  benefits  have  been  reported  in  productivity,  software  portability,  portability  of  program¬ 
mers  among  projects  using  a  single  language,  and  software  maintainability  and  reliability 
[193, 29, 107, 191].  An  area  where  Ada’s  inpact  has  been  positive  is  In  increased  productivity. 

While  productivity  may  decline  by  10  to  20  percent  during  the  first  two  to  three  Ada  projects,  produc¬ 
tivity  after  complete  transition  to  Ada  has  been  shown  to  increase  on  average  about  20  percent  [193]. 
Ada  projects  seem  to  concentrate  greater  effort  in  the  early  stages  of  the  software  development 
process  and  have  achieved  sizable  reductions  in  error  rates  —  signs  of  improved  software  engineer¬ 
ing  practices  that  have  been  facilitated  through  the  use  of  Ada.  Additionally,  Ada  provides  a  common 
basis  for  using  tools  and  methodologies  along  with  new  capabilities  for  managing  system  complexity. 
Cost  savings  accrue  in  terms  of  the  numbers  of  unique  configurations  needed  to  maintain  software 
written  in  Ada. 


See:  Sections  3.1 , 3.3, 4.1 .1 .2. 


^Information  identifying  many  efforts  that  have  used  Ada.  both  defense-related  and  commercial,  is  available  from  the  Ada 
Information  Clearinghousa  Ada  Usage  Database.  (See  Appendix  B.3  for  contact  information.) 
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OuMtlon:  What  are  some  of  the  inhibitors  to  adopting  Ada? 

Answer:  The  following  inhibitors  have  been  encountered  in  adopting  Ada: 

Compiler  availability:  Most  major  processors  in  use  today,  ranging  from  specialized  digital  signal 
processors  (DSP)  to  microprocessors  to  mainframe  computers  and  super  computers,  have  Ada  com¬ 
pilers.  ITiere  were  501  fofa/ validated  Ada  compilers  on  the  official  AJPO  list  (as  of  October  1992). 
This  number  has  grown  from  78  validated  compilers  in  May  1987,  and  only  14  in  early  1986.  See 
Appendices  A.2  and  B.3  for  online  and  printed  sources  of  the  current  listing.  If  no  compiler  is  avail¬ 
able  for  the  selected  hardware,  see  Section  7.2.1  for  an  action  plan  and  several  alternative  solutions. 

Ada  and  embedded  systems:  The  Ada  language  design  team  emphasized  supporting  modem 
software  engineering  practices;  the  result  is  a  language  with  wide  applicability  in  devetoping  well- 
engineered,  quality  software.  In  fact,  Ada  has  been  used  successfully  for  MIS  and  Corporate  Infor¬ 
mation  Management  (CIM)  applications  [87].  There  are  no  technical  reasons  why  Ada  cannot  be  used 
successfully,  and  cost-effectively,  for  such  applications  [64, 87]. 

DoD  policy  and  Ada:  Current  DoD  policy  requires  that  Ada  be  used  for  new  defense  systems  and  for 
major  software  upgrades  of  existing  systems,  where  cost  effective.  See  Section  3.2  for  a  brief  descrip¬ 
tion  of  the  waiver  process  for  efforts  that  cannot  comply  with  the  policy. 

New  technology:  A  new  technology  always  introduces  risks,  but  now  that  Ada  has  matured,  the  risks 
from  adopting  Ada  have  been  significantly  reduced.  Recent  studies  have  shown  that,  in  organizations 
that  have  completed  several  Ada  projects,  Ada  can  be  at  least  as  cost-effective,  if  not  more  so,  as 
other  languages  that  have  traditionally  been  used  for  developing  large,  software-intensive 
systerrtt  [39, 193, 81]. 

Lack  of  knowledge:  A  lack  of  knowledge  of  software  engineering  and  Ada  can  delay  the  transition  to 
Ada.  Software  engineering  has  not  yet  attained  the  recognition  or  acceptance  of  other  academic 
disciplines.  Education  in  software  engineering  is  not  as  available,  comprehensive,  or  complete  as  in 
established  engineering  disciplines.  An  effective  training  program  is  a  key  part  of  developing  an 
organization's  software  engineering  capability  [14^.  Ada  training,  supported  by  appropriate  software 
engineering  training,  can  assist  an  organization  In  Improving  that  capability. 

DoD  procurement  process:  The  current  procurement  process  may  not  be  conducive  to  Ada  adop¬ 
tion  and  long-term  software  engineering  improvement.  A  recent  survey  of  Ada  adoption  indicates  that 
lowest  development  cost  still  is  the  major  award  factor  on  DoD  contracts,  and  that  defense  contractors 
perceive  the  DoD  as  unwilling  to  trade  tower  life-cyde  cost  for  greater  development  cost  [49]. 

Early  perceptions:  In  the  face  of  criticisms  of  early,  and  thus  immature,  Ada  implementations,  there 
has  been  little  advertising  of  successful  Ada  efforts,  such  as  those  described  in  [87, 94]  or  the 
Experience  track  of  the  TRI-Ada  conferences  [108, 97, 38],  and  little  concerted  effort  to  gather, 
analyze,  and  distribute  objective  data  about  the  economic  impact  of  Ada  on  the  software  engineering 
discipline.  The  early  bad  press  has  left  a  legacy  because  of  weaknesses  of  early  implementations  and 
the  experiences  of  early  Ada  projects. 

Language  Issues:  Real  and  perceived  language  limitations  have  hampered  the  adoption  of  Ada. 

The  Ada  Joint  Program  Office  (AJPO)  has  emphasized  a  strict  validation  process  that  has  yielded 
hundreds  of  validated  compilers.  Great  progress  has  been  made  in  Ada  compiler  technology,  includ¬ 
ing  the  development  of  optimizing  compilers  for  many  processors.  Clearly,  the  image  of  Ada  im- 
plemerrtations  having  poor  performance  and  quality  is  much  outdated;  projects  should  evaluate  Ada 
implementations  in  light  of  their  specific  requirements. 
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Integration  with  computer-aided  software  engineering  (CASE)  tools:  Current  CASE  tools  are 
poorly  integrated  with  most  Ada  implementations.  Integrated  environments  that  support  some  of  the 
software  engineering  discipline  encouraged  by  Ada  are  continuing  to  be  developed. 

See:  Sections  3.2, 4.2.2. 

Question:  Who  manages  Ada? 

Answer:  The  Ada  language  effort  is  managed  by  the  Ada  Joint  Program  Office  (AJPO),  a  DoD  office 
whose  responsibilities  include: 

•  maintaining  Ada  as  military,  Federal  Information  Processing  Standard  (FIPS),  ANSI,  and  ISO 
standards,  among  others, 

•  developing  compiler  validation^  procedures  and  guidelines, 

•  certifying  facilities  that  perform  validation  of  Ada  compilers, 

•  coordinating  the  development  of  evaluation  suites  for  Ada  compilers,  and 

•  coordinating  DoD  Ada  training  and  education  activities. 

Stability  of  the  language  Is  an  Important  consideration.  Unlike  many  other  languages  where  dialects 
and  multiple  versions  have  emerged,  consistency  over  an  extended  period  of  time  has  been  stressed. 
Subsets  and  supersets  are  discouraged,  and  compiler  validation  is  used  to  ensure  compliance  to  the 
language  standard.  The  Ada  9X  Project  Office  is  managing  the  efforts  to  revise  the  Ada  language 
standard  (ANSI/MIL-STD-1815A)  and  to  coordinate  this  revision  with  the  international  community  to 
ensure  Ada  9X  adoption  as  an  ISO  standard. 

See:  Appendix  B.3. 

Question:  What  is  the  Ada  9X  Project?  What  will  its  impact  be? 

Answer:  The  Ada  language  standard,  ANSI/MIL-STD-1815A,  was  published  in  1983.  In  1988,  it  was 
recommended  that  the  Ada  standard  be  revised.^  The  Ada  9X  Project®  Is  the  effort  to  revise  the 
standard  for  the  Ada  programming  language,  obtain  adoption  of  the  revised  standard,  and  effect  a 
srTX)Oth  transition  from  Ada  83  to  Ada  9X. 

The  revisions  leading  to  Ada  9X  are  intended  to  include  only  those  changes  that  improve  the  usability 
of  the  language  and  minimize  the  disruptive  effects  of  changing  the  standard.  This  is  critical,  as  a 
significant  infrastnjcture  and  investment  exist  in  Ada  83.  Ada  9X  is  planned  to  be  mostly  upwardly 
compatible  with  Ada  83  (i.e.,  most  Ada  83  programs  will  compile  and  njn  under  Ada  9X  compilers). 

The  Ada  9X  standard  will  incorporate  improvements  in  object-oriented  programming,  programming-in- 
the-large,  and  real-time  capabilities.  ANSI  approval  of  the  Ada  9X  standard  is  expected  in  1994.  DoD 
and  National  Institute  of  Standards  and  Technology  (NIST)  adoption  of  the  ANSI  Ada  9X  standard  will 
follow,  and  ISO  approval  will  take  at  least  two  years  eifter  ANSI  approval,  due  to  voting  procedures.  In 
addition,  the  Ada  9X  Project  is  taking  several  steps  to  hasten  the  availability  of  usable  Ada  9X  tools, 
including  a  change  in  the  concept  of  the  Ada  language  standard  In  terms  of  a  core  language  and 
several  annexes,  which  provide  extended  features  for  specific  application  areas. 


*See  Sections  2.3  and  6.2. 1  for  an  explanation  of  compiler  validation. 

Standards  organizations  (such  as  ISO  or  ANSI)  require  that  all  starrdards  be  periodically  reaffirmed,  revised,  or  allowed  to  lapee. 
This  is  not  unique  to  Ada;  all  standards  (including  standardized  languages)  must  undergo  this  process  periodically. 

*For  more  information  about  the  Ada  9X  Project,  see  Section  9.  For  contact  information  on  the  Ada  9X  Project  Office,  see 
Appendix  B.3. 
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For  the  program  manager,  some  Ada  9X  issues  will  be  especially  relevant  (e.g.,  which  Ada  standard 
to  apply,  when  to  transition  the  program  to  Ada  9X  or  to  continue  doing  upgrades  using  Ada  83).  Use 
of  Ada  83  for  some  projects  is  anticipated  to  continue  well  into  the  next  decade. 

See:  Section  9,  Appendix  B.3. 


2.2.  Costs 

The  following  questions  are  covered  in  this  section: 

•  Will  Ada  save  money? 

•  What  impact  will  Ada  have  on  hardware  requirements? 

Question:  Will  Ada  save  money? 

Answer:  Software  development  and  maintenance  organizations  that  use  a  single,  modem,  high-order 
language  will  save  money.  Individual  progrants  that  have  not  already  adopted  Ada  will  incur  some 
one-time  start-up  costs  for  software  tools,  training,  and  development  hardware  (although  in  some 
cases,  these  costs  may  be  shared  by  several  programs).  However,  in  the  long  mn,  the  use  of  Ada  is 
expected  to  reduce: 

•  individual  program  development  and  maintenance  costs  because  of  better  software  develop¬ 
ment  methods,  and 

•  overall  costs  through  reduce  post-deployment  software  support  (PDSS)  costs  by  using  a 
single  language  for  many  programs. 

See:  Sections  3.1, 3.3, 5, 6.2, 6.3. 

Question:  What  impact  will  Ada  have  on  hardware  requirements? 

Answer:  This  question  requires  an  examination  of  both  host  (or  development)  computer  resources 
and  target  computer  resources. 

•  Host  computer;  Ada  compilers  require  somewhat  more  host  computing  resources  than  do 
compilers  for  most  other  languages,  in  part  because  Ada  compilers  detect  many  more  pro- 
grammi^  errors  earlier  in  the  development  process  (thereby  saving  time  raring  software 
integration)  and  provide  greater  levels  of  support  for  building  large  software  systems  than  do 
other  languages. 

•  Target  computer;  Ada  compilers  have  been  demonstrated  to  be  as  efficient  as  compiiers  for 
other  languages.  It  is  quite  reasonable  today  to  expect  that  Ada  compilers  will  generate 
efficient  code  tor  resource-constrained  machines.  Of  course,  as  with  selecting  any  program¬ 
ming  language,  candidate  compilers  should  be  evaluated  to  ensure  that  they  satisfy  the 
needed  code  efficiency;  not  every  vendor  has  emphasized  target  code  efficiency. 

See:  Sections  6.2.2, 6.2.2. 1, 6.2.2.2, 7.2, 7.3. 
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2.3.  Technical  Issues 

The  following  questions  are  covered  in  this  section: 

•  What  is  the  current  status  of  Ada  compilers?  Which  compilers  are  most  appropriate  for  a 
program? 

•  What  is  validation?  How  does  the  requirement  to  use  only  validated  compilers  affect  a  program 
that  must  modify  its  compiler? 

•  What  is  the  purpose  of  an  Ada  program  design  language  (PDL)? 

•  Can  Ada  be  used  on  MIL-STD-1750A  [73]  computers?  On  the  Motorola  68000  family?  On 
reduced  instruction  set  computers  (RISC)  processors  or  32-bit  processors?  Are  any  of  these 
processors  more  appropriate  to  use  with  Ada? 

•  Should  every  processor  in  a  system  be  programmed  in  Ada? 

•  Can  Ada  be  used  in  distributed  applications? 

•  What  is  runtime  software  and  why  are  runtime  issues  important? 

•  What  is  software  portability?  How  can  portability  be  maximized? 

•  Can  Ada  be  mixed  with  other  languages? 

•  Are  there  risks  In  automatically  translating  existing  systems  to  Ada? 

•  Can  commercial  off-the-shelf  (COTS)  software,  database  management  packages,  and  fourth- 
generation  ianguages  still  be  used  with  Ada? 

•  Can  Ada  help  with  software  reuse? 

•  Is  Ada  an  object-oriented  prograrrvning  language?  Can  Ada  be  used  to  implement  an  object- 
oriented  design? 

•  Can  cost  and  schedule  risk  be  reduced  by  using  C-m-  instead  of  Ada? 

Question:  What  is  the  current  status  of  Ada  compilers?  Which  compilers  are  most  appropriate  for  a 
program? 

Answer:  Robust  Ada  compilers  are  now  available  for  a  variety  of  processors,  especially  the  nwre 
common  ones  and  those  used  in  mission-critical  environments.  Execution  time  appears  to  be  com¬ 
parable  to  other  languages,  although  njntime  checks  (which  are  important  in  many  safety-criticat  or 
fault  tolerant  applications)  do  add  to  execution  time.  A  variety  of  utility  programs,  CASE  tools,  and 
training  aids  are  available  to  support  the  Ada  development  environment. 

Ada  compilers  are  suitable  now  for  applications  that  run  on  general-purpose  computers  with  no 
severe  memory  or  time-critical  performance  constraints.  For  performance  and  resource-constrained 
applications  (avionics,  fire  control,  etc.),  numerous  Ada  compilers  and  njntime  systems  exist  and  have 
matured.  Production  quality  com^lers  exist  today.  Today,  the  availability  of  a  robust  compiler  for  any 
specific  host-target  pair  is  more  likely  affected  by  market  considerations  than  technical  ones.  That  is, 
compiler  vendors  will  support  those  products  for  which  there  is  sufficient  demand. 

Each  program  should  evaluate  the  quality  and  maturity  of  compilers  based  on  their  criteria,  consider¬ 
ing  such  factors  as  compile-time  efficiency,  object-code  efficiency,  additional  compiler  services,  and 
support  for  embedded  system  requirements.  Project-specific  benchmarks,  addressing  project-unique 
requirements,  provide  a  basis  for  evaluating  corr^lers  [226].  The  Ada  Compiler  Evaluation  Capability 
(ACEC)  [100, 153, 154, 155]  provides  a  standard  method  for  evaluating  Ada  compilers.^  Another 
method  of  compiler  evaluation  is  embodied  in  the  Ada  Evaluation  System  (AES),  developed  in  the 
United  Kingdom  [162].  These  two  benchmark  suites  are  currently  being  merged.  Also  in  use  are  the 


^Tbe  tint  release  of  the  ACEC  occurred  in  August  1968.  The  current  ACEC  (Version  V3)  was  released  in  August  1992. 


Performance  Issues  Working  Group  (PIWG)  benchmarks  [187],  which  test  performance  characteris¬ 
tics  of  the  software,  and  the  Hartstone  benchmarks  [93, 92],  which  test  a  system’s  ability  to  handle 
hard  real-time  applications. 

See:  Sections  6.2.2, 7.1, 7.2, 7.3,  7.4,  Appendix  B.i,  B.3. 

Question:  What  is  validation?  How  does  the  requirement  to  use  only  validated  compilers  affect  a 
program  that  must  rTX)dtfy  its  compiler? 

Answer:  Validation  is  a  process  developed  by  the  AJPO  to  test  the  compliance  of  an  Ada  compiler 
with  the  language  definition.  To  achieve  validation,  an  Ada  compiler  must  pass  the  Ada  Compiler 
Validatton  Capability  (ACVC)  standard  test  suite.  The  validation  process  could  be  viewed  as  an  initial 
test  of  a  compiler;  however,  validation  does  not  address  performance  areas  such  as  compiler  speed 
or  efficiency  of  the  generated  code,  so  validation  does  nor  imply  that  a  compiler  is  suitable  (in  terms  of 
quality  or  features)  for  use  by  a  specific  program.  According  to  the  current  validation  guidelines  [3], 
changes  can  be  made  to  a  compiler  as  long  as  they  do  not  change  the  language.  The  validation  tests 
should  be  run  against  a  customized  compiler  to  ensure  there  are  no  deviations  from  the  standard. 

See:  Section  6.2.1 ,  Appendix  B.3. 

Question:  What  is  the  purpose  of  an  Ada  program  design  language  (PDL)? 

Answer:  A  PDL  is  a  formal  notation  used  to  capture  design  decisions.  Ada's  features  for  structuring 
and  organizing  prograrrts  are  also  usable  during  the  design  process  to  describe  software  architecture 
(the  structure  of  a  system),  its  interfaces,  and  its  overall  behavior,  as  well  as  to  document  that  design. 
A  design  language  should  be  used  as  a  part  of  an  ovemll  software  methodology.  When  placing  an 
Ada  POL  on  contract,  attention  should  be  paid  to  how  well  it  is  integrated  Into  the  developer’s 
methodology.  Many  ongoing  procurements  have  called  for  the  use  of  an  Ada  PDL,  and  DoD  Instnjc- 
flon  5000.2®  [79]  suggests  the  use  of  a  PDL 

Some  advantages  of  an  Ada  PDL  are; 

•  Using  an  Ada  PDL  is  a  good  transition  strategy  —  the  designers  work  with  and  think  in  Ada 
terms  earlier  In  the  development,  thereby  potentially  easing  the  transition  from  design  to 
code. 


•  An  Ada  PDL  should  be  compilable  Ada  (conforming  to  the  language  standard);  then  it  can  be 
checked  by  an  Ada  conrpiler  on  the  host  machine  tor  consistency  and  completeness.  An 
Ada  PDL  also  provides  a  description  of  a  design,  useful  not  only  to  reviewers  and  others,  but 
which  can  also  be  checked  for  interface  errors. 

•  When  made  a  part  of  the  documentation  requirements  for  software  design  documents,  an 
Ada  PDL  can  also  be  an  indicator  of  the  status  arxl  quality  of  a  contractor’s  design  efforts 
earty  in  the  development. 

Some  disadvantages  of  an  Ada  PDL  are: 

•  Ada  PDL  has  sometimes  been  applied  in  cases  where  the  eventual  implementation  has  been 
in  a  language  other  than  Ada.  While  this  is  technically  feasible,  it  has  been  difficult  to  carry 
out  in  practice,  and  should  perhaps  be  avoided  unless  the  designers  can  demonstrate  an 
adequate  understanding  of  modem  software  engineering  principles  and  implementation 
tradeoffs. 


DoD  Instruction  5000.2  (79)  calls  ter  the  use  of  capable  software  processes  and  practices,  including  the  *use  of  automated  tools, 
such  as  computer  aided  software  engineering  (CASE)  tools  or  formal  manual  techniques  such  as  program  design  language  and 
structured  flowcharts.'  For  more  information  about  applying  formal  methods  to  Ada  efforts,  see  [156, 188). 
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•  Some  aspects  of  design  (e.g.,  performance  requirements,  traceabiiity  to  requirements  docu¬ 
ments)  are  rK>t  readily  captur^  in  an  Ada  PDL.  Structured  comments  known  as  annotations 
can  be  used  to  capture  some  of  this  information  so  that  the  resulting  design  is  still  compil¬ 
able.  Other  aspects  of  a  design  (e.g.,  the  overall  design  stmcture)  are  better  represented 
with  other  notations  [129]. 

There  is  no  standard  Ada  PDL;  however,  several  POL  processing  tools  are  available,  and  there  is  an 
IEEE  standard  recommended  practice  for  Ada  as  a  PDL  [132]. 

Question:  Can  Ada  be  used  on  MIL-STD-1750A  [73]  computers?  On  the  Motorola  68000  family?  On 
reduced  instmction  set  computers  (RISC)  processors  or  32-bit  processors?  Are  any  of  these  processors 
more  appropriate  to  use  with  Ada? 

Answer:  Many  existing  compilers  are  mature  for  these  processors.  However,  the  mere  existence  of  a 
compiler  is  rK>t  indicative  of  its  quality  or  maturity.  The  quality  of  the  code  generated  by  the  compiler 
(how  well  the  application  software  will  run)  is  somewhat  dependent  on  the  capabilities  of  the  target 
hardware.  While  Ada  does  run  on  the  processors  mentioned  above,  Ada  (and  all  modem  program¬ 
ming  languages)  is  best  supported  on  processors  with  large  memory  capability  arxl  instructions  for 
conveniently  accessing  that  storage. 

See:  Sections  6.2.2, 7.2, 7.3. 

Question:  Should  every  processor  in  a  system  be  programmed  in  Ada? 

Answer:  Certain  situations  require  the  use  of  special  processor  technology  that  is  inconpatible  with 
any  general-purpose  language,  including  Ada.  Some  processors  have  highly  specialized  functions 
(e.g.,  a  Fast  Fourier  Transform  chip).  Often  these  processors  cannot  in  any  practical  sense  support 
all  the  functions  typically  required  by  a  high-order  language.  Other  small  processors  are  often  used  to 
provide  limited  functionality  in  a  given  situation  (e.g.,  processors  with  limfted  address  space  and 
register  set  used  for  built-in  test  functions  within  an  electronics  assembly  or  as  an  input-output  proces¬ 
sor  for  a  control  panel).  It  may  not  always  be  appropriate  to  use  Ada  or  any  other  general-purpose, 
high-order  language  on  such  processors  because  the  expense  of  building  the  necessary  support  toois 
is  expected  to  be  high,  and  the  advantages  inherent  in  these  specialized  processors  may  be  lost  by 
using  languages  for  which  the  hardware  was  not  intended.  However,  since  it  is  likely  that  these 
processors  will  be  used  in  systems  in  conjunction  with  generai-purpose  processors  whose  software 
has  been  developed  in  Ada,  the  interfaces  and  communication  between  the  processors  are  important 
for  system  engineering  attention. 


See:  Sections  7.2, 7.3. 


Question:  Can  Ada  be  used  in  distributed  applications? 

Answer:  Some  forms  of  distributed  applications,  especially  loosely  coupled  distributed  systems,  can 
be  irrplemented  using  Ada  today,  as  was  previously  done  with  other  languages,  such  as  JOVIAL  and 
FORTRAN.  With  the  introduction  of  software  technology  currently  in  development,  more  sophis¬ 
ticated  methods  that  take  advantage  of  Ada's  tasking  features  should  become  available.  Ada  9X  is 
planned  to  provide  increased  support  for  distributed  appiications. 

See:  Sections  7.4,  7.5, 9. 
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Question:  What  is  njntime  software  aixl  why  are  runtime  issues  important? 


Answer:  Runtime  software  provides  the  additional  supporting  functions  required  for  executing  Ada 
programs  on  a  specified  target  computer.  Each  target  computer  and  each  language  places  require¬ 
ments  on  the  runtime  software.  Ada  mntime  software  is  responsible  for  functions  such  as  scheduling, 
parameter  passing,  storage  allocation,  and  some  kinds  of  error  handling  (much  like  the  custom  "ex¬ 
ecutive  software”  written  for  applications  developed  in  other  languages,  such  as  CMS-2,  JOVIAL,  and 
FORTRAN). 

For  further  detailed  discussion  of  runtime  systems,  see  [224, 1 6, 1 7, 1 8, 89, 90, 91 , 28, 1 0, 25, 26]. 
See:  Sections  6.2.2.2, 7.4. 


Question:  What  is  software  portability?  How  can  portability  be  maximized? 

Answer:  Software  portability  describes  the  extent  to  which  computer  software  can  be  moved  without 
source-level  modification  between  different  computer  systems.  Portability  has  traditionally  been  a 
significant  problem  due  to  the  proliferation  of  programming  languages  and  their  dialects.  (FORTRAN 
is  a  classic  example  of  a  programming  language  with  many  dialects.)  While  some  modification  will 
almost  always  be  required  when  moving  software  from  system  to  system,  Ada  compares  favorably  to 
other  languages  because  of: 

•  enforcement  of  the  standard  via  the  requirement  for  compiler  validation,  and 

•  language  features  (packages  and  private  types)  that  allow  software  developers  to  isolate 
machine-dependent  software.  Through  use  of  these  features,  the  scope  of  required 
modifications  is  localized  and  chances  of  errors  diminished. 

Of  course,  Ada  software  must  be  properly  designed  to  maximize  portability;  portability  must  be  con¬ 
sidered  a  design  objective. 

See:  Sections  8.1 .1 , 8.1 .3, 6.2.1 , 6.2.2.4. 

Question:  Can  Ada  be  mixed  with  other  languages? 

Answer:  Mixing  languages  is  possible  and  can  result  in  productivity  enhancements.  Various  projects 
have  accomplished  this  successfully.  An  example  of  mixing  languages  is  calling  the  FORTRAN  Inter¬ 
national  Mathematical  and  Statistical  Library  (iMSL)  from  Ada. 

However,  program  managers  should  realize  that  if  multiple  language  support  is  required,  then  poten¬ 
tial  Ada  compilers  must  be  evaluated  with  respect  to  their  capability  to  mix  languages.  There  are 
various  levels  of  integration  that  can  be  achieved  when  interfacing  Ada  with  other  languages,  existing 
systems,  or  commerciai  off-the-shelf  (COTS)  software.  In  some  instances,  the  desired  integration  can 
be  obtained,  but  will  be  unique  to  the  particular  implementation  or  not  easily  portable  to  another 
implementation. 

See:  Sections  6.2.2, 8.2, 8.4.1. 


Question:  Are  there  risks  in  automatically  translating  existing  systems  to  Ada? 

Answer:  There  are  significant  risks  in  attempting  automatic  translation  from  any  programmir)g  lan¬ 
guage  to  another,  and  this  strategy  is  generally  not  recommended  as  a  means  of  achieving  Ada- 
based  software.  A  thorough  analysis  of  technical,  cost,  arxJ  life-cycle  issues  should  be  accomplished 
before  committing  to  an  automatic  translation  approach.  Re-engineering  existing  systems  may  be  the 
most  effective  way  to  achieve  the  desired  results  [46]. 

See:  Section  8.4.4. 
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Question:  Can  commercial  off-the-shelf  (COTS)  software,  database  management  packages,  and  fourth- 
generation  languages  (4GL)  still  be  used  with  Ada? 

Answer:  Ada  applications  can  effectively  use  whatever  resources  (i.e.,  operating  systems  or  com¬ 
munications  services,  database  management  systems,  gr^hics  packages  or  user  interface  manage¬ 
ment  systems,  or  interfaces  to  COTS  software  or  other  existing  systems)  are  needed  to  produce  a 
complete  system.  Ada  interfaces  to  many  other  systems  and  standards  are  available  [133],  For 
example,  Ada-SQL  interfaces,  or  bindings,  exist.  New  implementations  of  interfaces  (or  bindings)  are 
continuing  to  emerge.  Since  much  attention  is  presently  being  paid  to  successful  integration  of  Ada 
software  in  overall  systems  environments,  program  managers  should  determine  if  bindings  exist  be¬ 
fore  beginning  additional  development. 

Fourth-generation  languages,  when  used  in  their  proper  domain,  make  significant  increases  in 
productivity  possible.  Some  applications  may  indeed  be  suitable  for  fourth-generation  language  ap¬ 
proaches.  However,  4GLs  typically  provide  productivity  gains  only  through  reductions  in  coding  ef¬ 
forts  and  can  prove  very  costly  if  used  to  satisfy  requirements  even  slightly  outside  their  domain  of 
applicability.  Service-specific  policies  identify  the  requirements  for  waivers  or  exceptions  when  using 
such  technologies. 

See:  Sections  8.2, 8.3.4, 3.2.3. 

Question:  Can  Ada  help  with  software  reuse? 

Answer:  Many  functions  in  new  software  systems  are  similar,  if  not  identical,  to  those  in  previously 
developed  systems.  Reusing  existing  system  requirements,  design,  and  code  and  applying  them  to 
new  development  efforts  or  porting  existing  software  to  new  hardware  configurations  has  the  potential 
to  significantly  reduce  development  costs  and  to  produce  more  reliable  systems.  Ada's  standar¬ 
dization  and  some  of  its  special  features  mean  that  Ada  is  especially  suitable  for  promoting  software 
portability  and  reuse.  These  language  features  are  available  to  facilitate  portability  and  reuse  of  both 
software  code  and  software  architectures. 

See:  Section  8.1 . 


Question:  is  Ada  an  object-oriented  programming  language?  Can  Ada  be  used  to  implement  an  object- 
oriented  design? 

Answer:  Object-oriented  methodologies  can  be  used  in  specifying  requirements,  designing,  and  im¬ 
plementing  systems  using  Ada  (177, 203, 120, 2, 20, 150). 

Ada  83  has  been  referred  to  as  an  "object-based*  language,  but  It  is  not  a  complete  "object-oriented" 
programming  language  because  it  does  not  support  full  inheritance  and  runtime  polymorphism.^  Ada 
9X  will  extend  the  "object-based*  features  of  Ada  83  (such  as  abstract  data  types  and  derived  types) 
to  incorporate  the  object-oriented  class  concept^®  and  will  be  fully  supportive  of  object  orientation. 

Object-oriented  design  (OOD)  typically  refers  to  a  variety  of  design  strategies  (e.g.,  Booch)  that  Ada 
supports  well.  Object-oriented  programming  (OOP)  refers  to  a  programming  paradigm  involving  in¬ 
heritance  of  classes,  which  Ada  83  does  not  support  well  (201],  but  Ada  9X  will  support  better.  Com¬ 
mercial  products,  such  as  language  preprocessors,  are  available  to  give  Ada  full  object-oriented 


*Se®  [223]  for  a  discussion  of  the  distinction  between  'object-based'  languages  and  'object-orientecT  languages  Inheritance  is  a 
means  for  inmmentally  building  new  absti^ons  from  existing  ones  by  'inheriting’  their  properties  —  without  disturbing  the  original 
abstractions'  implementation  or  other  inherited  uses  (7).  Poly/norphism  is  a  means  of  factoring  out  differences  among  a  collection  of 
abstractions  such  that  programs  may  be  written  in  terms  of  their  common  properties  [7]. 

^°For  a  more  detailed  summary  of  these  enhancements,  see  [21 S]. 
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capabilities.  There  is  nothing  in  the  language  to  prevent  software  from  being  implemented  in  Ada 
based  on  object-oriented  requirements  analysis  (OORA)  or  object-oriented  design. 

See:  Section  9. 

Question:  Can  cost  and  schedule  risk  be  reduced  by  using  C-m-  instead  of  Ada? 

Answer:  Software  for  large,  complex  applications  must  be  engineered.  It  was  precisely  these  kinds  of 
large  applications  that  Ada  was  designed  for.  in  general,  DoD  policy  requires  that  Ada  be  used  for 
defense  software,  and  a  waiver  must  be  approved  to  use  another  language.  A  waiver  request  must 
address  the  justification  for  the  request,  life-cycle  cost  analysis,  and  risk  analysis  addressing  technical 
performance  and  schedule  impact. 

Although  it  is  apparent  that  C/C++  has  gained  widespread  market  acceptance  in  recent  years, 
popularity  arxi  market  acceptance  are  rwt  always  indicators  of  technical  superiority,  rK>r  are  they 
reasons  for  choosing  one  language  over  arK>ther  for  a  particular  application.  Language  comparisons 
are  often  futile  efforts  because  they  fail  to  consider  the  context  (i.e.,  application  domain  and  require¬ 
ments,  hardware  and  software  tradeoffs,  projected  system  life  cycle,  and  associated  development  and 
support  costs)  in  which  the  language  will  be  used. 

The  Air  Force  conducted  a  study  to  examine  the  ciroimstances  in  which  the  use  of  C-m-  might  be 
justified  for  OoD  software  development  [81].  Each  portion  of  this  study  reached  the  same  conclusion: 
Ihere  is  no  compelling  reason  to  waive  the  Ada  requirement”  to  use  C-m-.  Particularly  noted  were 
Ada’s  suitability  for  large  systems,  its  safety  (ability  to  detect  errors),  and  its  maturity  (through  standar¬ 
dization  and  compiler  validation)  as  compared  to  C-m-. 

Until  Ada  9X  is  available,  &m-  may  provide  some  advantages  for  object-oriented  programming.  For 
small  systems  or  prototypes  where  existing  class  libraries  can  be  used  to  build  systems  from  com¬ 
ponents,  it  may  be  possible  to  justify  C-i-i-  on  a  cost  and  schedule  basis,  just  as  4GLs  can  be  justified 
for  certain  applications.  However,  waivers  will  generally  not  be  justified  by  lower  development  cost  or 
lower  risk  for  large,  long-lived,  or  safety-critical  DoD  ap^ications,  as  life-cycle  issues  are  the  drivers 
for  these  systems. 

See:  Section  4.2.2. 


2.4.  Program  Management 

The  following  questions  are  covered  in  this  section: 

•  What  Ada  training  sources  exist?  What  topics  should  be  emphasized? 

•  What  is  the  best  strategy  for  an  organization  that  has  little  or  no  experience  developing  systems 
in  Ada? 

•  How  should  those  proposing  Ada  be  evaluated  during  the  source  selection  process? 

•  Will  changes  be  required  in  software  management  methods  (e.g.,  design  walkthroughs  and  code 
inspections)? 

•  Compared  to  other  languages,  how  many  source  lines  of  code  (SLOC)  will  Ada  require  for  equiv¬ 
alent  functions? 

•  Will  Ada  affect  cost-estimating  rrxxJels? 

•  How  productive  can  Ada  software  developers  be? 

•  Can  Ada  be  used  with  DoD  software  development  standards? 

•  Wh£tt  effect  does  Ada  have  on  configuration  management  (CM)? 
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Question:  What  Ada  training  sources  exist?  What  topics  should  be  emphasized? 

Answer:  Ada  training  courses  are  available  from  a  wide  variety  of  government,  academic,  and  com¬ 
mercial  sources.  To  obtain  the  full  benefits  of  using  Ada,  software  engineering  concepts  should  be 
taught  as  an  integral  part  of  the  overall  training  program,  since  many  software  developers  do  not  have 
the  appropriate  background  in  this  area.  Additionally,  hands-on  design  and  programming  exercises 
are  essential  for  software  developers.  The  training  needs  of  managers  and  other  personnel  (e.g., 
application  specialists,  lead  designers,  software  engineers,  and  testing  personnel)  should  be  con¬ 
sidered  in  planning  a  transition  to  Ada. 

See:  Section  5,  Appendix  B.3. 


Question:  What  is  the  best  strategy  for  an  organization  that  has  little  or  no  experience  developing  sys¬ 
tems  in  Ada? 

Answer:  There  are  many  approaches  (for  example,  addressing  compiler  and  tool  acquisition  and 
system  engineering  concerns)  that  are  detailed  in  other  chapters  of  this  handbook.  Perhaps  most 
important,  given  this  situation,  is  to  develop  an  internal  cadre  of  skilled  Ada  personnel. 

See:  Sections  4.1 .2. 4.3, 5,  Appendix  B. 

Question:  How  should  those  proposing  Ada  be  evaluated  during  the  source  selection  process? 

Answer:  In  general,  contractor  evaluation  should  be  done  in  a  manner  similar  to  that  used  for  other 
software  developments  [40, 80, 47, 82, 62, 51. 22  (Section  10)].  Expertise  in  Ada  and  software  en¬ 
gineering  should  be  a  major  discriminator  in  contract  awards.  A  proven  record  of  application-clomain 
expertise  and  meeting  cost,  schedule,  and  quality  requirements  is  important.  Additionally,  an  assess¬ 
ment  of  Ada  capabilities  is  necessary  In  terms  of  people,  software  tools,  training,  methodology, 
management,  ongoing  internal  research  and  development  efforts,  and  previous  developments; 
program  risk  increases  if  a  contractor  attempts  a  large  Ada  development  without  any  Ada  experience. 
Finally,  Ada-knowledgeable  staff  can  be  consulted  as  part  of  the  evaluation  process. 


Question:  Will  changes  be  required  in  software  management  methods  (e.g.,  design  walkthroughs  and 
code  inspections)? 

Answer:  While  software  management  techniques  such  as  design  walkthroughs  and  code  inspections 
still  apply,  experience  on  Ada  projects  indicates  that  the  levels  of  effort  and  time  associated  with  the 
various  phases  of  the  software  life  cycle  have  changed  with  the  use  of  Ada.  Experience  to  date 
indicates  the  need  to  spend  more  time  in  the  definition  and  design  phases  and  less  time  in  testing  and 
integration  than  was  spent  in  previous  efforts.  Increased  emphasis  on  the  design  phase  will  lessen 
the  time  involved  in  testing  and  integration,  since  many  errors  will  be  identified  early  in  the  develop¬ 
ment  [24, 29],  and  may  also  deaease  the  time  required  in  the  coding  phases  [175, 193].  Some  rules 
of  thumb  to  use  regarding  ievels  of  effort  are; 


Phase 


Design 

Code 

Test  and  Integration 
See:  Section  4.1 .1 .2. 


Other  Ada 

Languages 


40%  50%  + 

20%  15%-30% 

40%  20%-35% 
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Question:  Compared  to  other  languages,  how  many  source  lines  of  code  (SLOC)  will  Ada  require  for 
equivalent  functions? 

Answer:  Software  measures  are  useful  for  gaining  insight  into  a  software  program.  Software  size, 
often  measured  in  terms  of  source  lines  of  code  (SLOC),  is  one  such  measure.' '  There  are  many 
different  views  of  what  a  source  line  of  code  is  and  how  to  use  the  computed  values  [104].  Although 
the  validity  of  SLOC  has  been  questioned,  and  numerous  definitions  and  counting  schemes  exist,  an 
understanding  of  the  issues  and  concerns  is  important,  since  SLOC  is  sometimes  used  as  an  in¬ 
dicator  of  system  complexity,  system  hardware  requirements  (processors  and  memory),  and  as  a 
basis  for  computing  system  cost. 

Any  estimates  comparing  Ada  and  other  languages  are  /nexact  since  factors  such  as  individual 
capabilities,  application  characteristics,  domain  complexity,  design  and  coding  techniques,  and  ian- 
guage  feature  use  will  exert  strong  influences.  The  counting  technique  used  will  also  make  a  substan¬ 
tial  difference  [104].  A  number  of  sources  have  identified  definitions  of  SLOC  and  counting  methods; 
these  include  [182, 230, 194, 176].  Regardless  of  the  definition  used,  it  is  imperative  that  lines  of 
code  be  estimated  and  counted  in  a  consistent  fashion. 

Following  are  genera/ comparisons  between  Ada  and  other  languages  using  the  number  of  source 
statements  per  function  point'^  [139]:  it  should  be  noted,  however,  that  as  software  reuse  and 
generics  become  more  common,  the  number  of  original  lines  (that  have  to  be  written  from  scratch) 
may  well  decrease. 


Language 

Source  Statements 
per  Function  Point 

Assembly 

320 

C 

128 

FORTRAN  77 

105 

ANSI  COBOL  74 

105 

Pascal 

91 

Ada 

71 

Fourth  generation  language  (4GL) 

20 

Table  2'1 :  General  Comparison  of  Ada  and  Other  Languages 


Jones  [139]  notes  that  these  are  general  trends  and  that  great  variability  caused  by  many  factors, 
including  differences  in  programming  styles,  can  influence  these  comparisons.  An  example  of  this  sort 
of  difficulty  in  making  language  comparisons  is  seen  in  comparing  parallel  Ada  and  FORTRAN  efforts 
[168].  The  resulting  two  systems  differed  in  several  measures  of  SLOC,  deper)ding  on  what  was 
counted.  A  major  difference  between  the  smaller  FORTRAN  and  the  larger  Ada  program  is  that  a 
substantial  amount  (at  least  30,000  SLOC)  of  additional  functionality  was  built  into  the  Ada  user 
interface,  and  that  the  coding  styles  for  Ada  were  not  the  same  as  the  FORTRAN  styles  (i.e.,  Ada 
used  longer  prologues  and  more  commenting).  Again,  much  of  this  comes  down  to  how  measure¬ 
ments  are  made,  what  is  being  measured,  and  the  variability  of  the  people  and  processes  used. 


"A  description  of  several  common  software  development  measures,  including  software  size,  can  be  found  in  [197). 

’*The  function  point  metric  was  developed  as  a  relative  measure  of  the  amount  of  user  function  delivered  to  the  user  or  customer 
independent  of  the  particular  technology,  language,  or  design  approaches  used  (9).  The  function  point  measure  is  claimed  to  be 
more  useful  than  SLOC  as  a  prediction  of  work  effort  because  this  measure  can  be  estimated  from  the  basic  requirements  for  a 
program  early  in  the  development  cycle. 
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Managers  are  urged  to  gather  and  use  data  as  part  of  a  meaningful  software  nf)easurement  process 
[30, 197].  In  this  way,  meaningful  numbers  for  both  lines  of  code  and  productivity  can  be  developed. 


Question:  Will  Ada  affect  cost-estimating  nmdels? 

Answer:  Several  of  the  major  cost-estimating  models  (REVIC,  COCOMO,  SOFTCOST,  etc.)  have 
been  revised  to  reflect  experience  with  Ada  [34, 142, 193, 143].  Experience  from  initial  Ada  programs 
indicates  that  several  cost  factors  will  change,  including  productivity,  definition  of  lines  of  code,  and 
levels  of  effort  associated  with  various  phases  of  development  [29, 191].  Cost  models  need  to  be 
recalibrated  to  reflect  differences  as  a  result  of  an  o^anization’s  use  of  Ada  [193]. 

See:  Section  4.1 .1.2. 

Question:  How  productive  can  Ada  software  deve topers  be? 

Answer:  While  only  a  few  definitive  Ada  productivity  studies  have  been  conducted 
[193, 168, 29, 107, 191],  Ada  software  development  efforts  generally  report  that  overall  productivity  is 
higher  than  for  other  languages.  Improvements  (after  an  organization’s  inKial  Ada  effort)  as  high  as  a 
factor  of  two  have  been  reported  informally  [1 68].  Studies  have  concluded  that  the  productivity  on  a 
third-time  Ada  project  result  in  a  slightly  tower  cost  than  that  of  an  equivalent  FORTRAN  project  and 
that  these  projects  show  significant  decreases  In  error  rates  [8,  p.  6-2].  Once  an  organization  has 
adopted  Ada,  average  productivity  gains  of  20  percent  have  been  reported  [193].  It  is  difficult  to  tell 
how  much  of  these  productivity  gains  is  a  direct  result  of  using  Ada,  and  how  much  is  attributable  to 
the  use  of  software  engineering  methods  and  techniques,  improved  software  processes,  increased 
levels  of  reuse,  and  domain-specific  architectures. 

However,  program  managers  should  be  aware  that  it  is  also  not  unusual  for  productivity  at  the  begin¬ 
ning  of  a  program  or  with  first  use  of  a  technology  such  as  Ada  to  be  tow  due  to  a  learning 
curve  [193, 145].  (A  good  training  program  is  essential  in  reducing  the  learning  curve.)  Additionally, 
cautious  use  of  reiMiled  data  is  recommended  since  productivity  will  vary  due  to: 

•  the  experience  and  capabilities  of  people, 

•  the  size  and  complexity  of  the  system  under  development, 

•  volatility  of  requirements  specifications. 

•  maturity  and  sophisticatton  of  the  software  development  environment,  and 

•  documentation  requirements. 

Question:  Can  Ada  be  used  with  DoD  software  development  standards? 

Answer:  Ada  can  be  used  with  DoO  software  development  standards  [74, 75, 72];  however,  as  with 
any  DoD  standard,  tailoring  may  be  required  for  the  particular  needs  of  any  program.  Discussion  of 
some  DoD-STD-2167  and  DoD-STD-2167A  related  issues  may  be  found  in  [221, 103, 116].  Sig¬ 
nificant  work  in  this  area  has  also  been  accomplished  by  the  ACM  SIGAda  Software  Development 
Standards  and  Ada  Working  Group  (SDSAWG).  Several  documents,  such  as  DoD-HDBK-287 
[76]  and  program-specific  guidance  [148],  have  been  developed  to  provide  guidance  in  tailoring  DoD- 
STD-2167A. 

See:  Section  4.1 .1.1,  Appendix  B.1 . 

Question:  What  effect  does  Ada  have  on  configuration  management  (CM)? 

Answer:  Disciplined  CM  practices  are  a  prerequisite  to  effectively  managing  Ada  software  develop¬ 
ment.  CM  for  small  and  moderately  sized  Ada  systems  (less  than  100,000  lines),  as  supported  by 
traditional  file  oriented  tools,’®  is  largely  indistinguishable  from  CM  for  systems  written  in  other  pro¬ 
gramming  languages. 


^^Examples  would  be  DEC'S  MMS  and  CMS  or  Unix  sees  and  make. 
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However,  the  CM  requirements  for  large  software  systems  tend  to  be  much  more  complex  than  for 
smaller  systems,  independent  of  programming  language.  This  is  especially  true  for  Ada,  which  is 
intended  for  the  design  and  development  of  large  systems.  Among  the  issues  that  have  to  be  ad¬ 
dressed  are  multiple  implementations  of  package  bodies,  and  the  growing  number  of  interdepen¬ 
dencies  among  objects  as  systems  increase  in  size. 

For  large  systems,  proper  system  management  will  require  support  from  the  program  library  since  the 
compiler  is  involved  in  supporting  functions  that  previously  had  been  managed  by  the  environment 
support  tools.  Since  CM  for  large  Ada  systems  is  an  area  for  concern,  the  program  manager  should 
ensure  that  Ada  program  libraries  provide  support  for  automatic  recompilation,  and  evaluate  the  level 
of  integration  between  the  Ada  compiler  and  the  project-selected  CM  tools.  Ada  does  have  an  impact 
on  CM  practices  because  Ada  code  sequences  are  placed  under  configuration  control  much  earlier  in 
the  development  process  than  was  true  for  other  languages,  primarily  because  of  Ada’s  use  as  a  PDL 
and  its  separate  compilation  features.  Performing  CM  for  Ada  requires  substantially  more  computing 
resources  than  for  other  languages  because  Ada  enforces  interface  compatibility  among  indepen¬ 
dently  compiled  nwdules. 


2.5.  For  More  Information  . . . 

Many  sources  of  information  are  listed  in  the  appendices  to  this  handbook.  Two  sources  are  included 
here  for  quick  reference: 

•  Ada  Joint  Program  Office  (AJPO):  Contact  Dr.  John  Solomond,  Director,  AJPO,  The  Pen¬ 
tagon,  Washington,  D.C.,  (703)  614-0208. 

•  Ada  Information  Clearinghouse  (AdalC):  Contact  the  AdalC  at  (703)  685-1477, 

(800)  AdalC-11,  FAX  (703)  685-7019,  or  electronicaliy  via  adainfo@ajpo.sei.cmu.edu  or  Com¬ 
puServe  70312,3303. 

See:  Sections  5.5,  Appendices  A,  B. 
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3.  The  Need  for  Ada 


3.1.  The  Software  Problem  and  Ada’s  Role 

Software  is  increasingly  being  recognized  as  a  serious  problem  in  the  development  of  mission- 
critical  systems,  regardless  of  whether  these  systems  are  embedded  systems  or  information 
systems  necessary  for  ongoing  operations.  Two  difficult  aspects  of  this  software  problem  are 
proper  development  (i.e.,  on  time,  within  budget,  with  required  functionality)  and  recognition  of 
Vie  need  to  prepare  tor  many  years  of  ongoing  software  support  and  enhancements.  Ada  was 
designed  to  address  these  problems  by: 

•  reducing  the  number  of  programming  languages  needed  so  effort  could  be  focused 
on  making  one  language  work  well;  and 

•  facilitating  the  use  of  modem  software  development  methods,  thereby  redudng  the 
costs  and  risks  of  software  development,  and  facilitating  improved  maintenance 
during  post-deployment  support. 

Many  DoD  and  industry  studies  have  documented  that  software  is  assuming  a  greater  share  of  system 
complexity  and  cost,  and  demand  for  quality  software  has  been  rising  faster  than  the  ability  to  produce  it. 
About  40  percent  of  the  functionality  of  the  F-1 6  fighter  depends  on  software  as  does  about  80  percent  of 
the  functionality  of  the  F-22  advanced  tactical  fighter  [144].  Indeed,  systems  of  hundreds  of  thousands, 
even  millions  of  lines  of  code  are  becoming  inaeasingty  common,  resulting  in  situations  where  computing 
systems  are  on  the  critical  path  to  systems  acquisition  and  among  its  leading  problems.'^ 

The  growing  importance  of  software,  in  terms  of  dollars  or  necessary  cap^ilities,  cannot  be  overstated. 
Some  estimates  have  predicted  that  DoO  software  costs  could  rise  as  high  as  $50  billion  by  2006  [218]. 
Col  Donald  Carter,  U.S.  Air  Force,  former  acting  deputy  undersecretary  of  Defense  for  Research  and 
Advanced  Technology,  tokJ  the  House  Armed  Senrices  Subcommittee  on  Research  and  Development 
that  "software  is  the  human  intelligence  that  is  programmed  into  our  systems.  It  allows  advanced  sensors 
to  discriminate  and  track,  navigation  systems  to  follow  prescnlsed  routes,  guidance  systems  to  control 
trajectories,  and  communications  systems  to  property  route  thousands  of  messages.  Software  keeps 
track  of  the  status  of  our  forces,  maintains  intelligence  information  on  enemy  forces,  and  aids  our  com¬ 
manders  in  deciding  on  target  actions”  [141]. 

Software  engineering  is  the  discipline  in  which  quality  (efficient,  reliable,  maintainable)  software  is 
produced  within  the  constraints  supplied  by  contractually  specified  acquisition,  development,  operational 
performance,  and  life-cycle  support  considerations.  Software  engineering  practice  today  lags  the  ideal  of 
a  robust,  mature  engineering  practice  [219].  The  DoD  is  aware  of  the  software  cost  and  technology 
insertion  problems  in  the  development  and  post-deployment  support  of  software,  and  established  a 
software  initiative  consisting  of  the  Ada  Program,  the  Software  Technology  for  Adaptable,  Reliable  Sys¬ 
tems  (STARS)  Program,  and  the  Software  Engineering  Institute  (SEI)  to  address  the  problem.  The  Ada 


illustrate  the  magnitude  of  a  delivered  1 ,000,000  (10^)  line  application  software  system,  assume  that  it  is  printed  on  8.5*  x 
1  r  paper  with  50  lines  per  page.  The  resulting  listings  would  be  a  stack  of  more  than  20,000  pages.  Assuming  that  500  sheets  is 
about  1 .5*  thick,  the  sta^  would  be  approximately  5  feet  high.  Note  that  the  above  sizing  omHs  any  consideration  of  code  to 
provide  the  software  development  environment,  simulation  software,  and  test  software,  and  also  omits  documentation,  contractually 
required  data  items,  and  presentation  material  (116). 
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language  effort  focuses  programming  development  methods  and  tools  on  a  single  language  that  supports 
modem  software  engineering  techniques.  Ada's  roie  as  the  singie,  common,  high-order  programming 
language  for  defense  systems  [79]  is  a  major  step  forward  in  addressing  DoD  software  development 
problems.  By  late  1989,  over  58  million  lines  of  Ada  code  for  defense  and  commercial  applications  were 
planned,  in  development,  or  being  maintained  [207]. 

3.2.  Policies  on  the  Use  of  Ada 

/^though  Ada  is  an  internationally  recognized  standard,  there  are  specinc  policies  that  man¬ 
date  its  use.  This  section  discusses  the  congressional  mandate,  DoD  policy,  and  the  policies 
of  the  DoD  services  and  other  agencies. 

In  March  1987,  the  International  Standards  Organization  (ISO)  approved  Ada  as  an  international  stan¬ 
dard,  ISO/8652-1987.  Programming  Languages  —  Ada.’®  This  ISO  standard  is  identical  to  the  DoD 
standard  adopted  for  Ada  [13]  and  provides  a  standard  language  definition  that  can  be  used  throughout 
the  DoD,  industry,  and  the  world. 

3.2.1.  Federal  Legislation 

Within  the  United  States,  policies  mandating  Ada 's  use  flow  in  part  from  federal  legislation. 

The  U.S.  Congress  enacted  legislation  (in  the  FY91  DoD  appropriations  bill.  Public  Law  101-51 1 ,  Section 
8092)  specifying  the  use  of  Ada  for  DoD  software  development: 

Notwithstanding  any  other  provisions  of  law,  after  June  1 , 1991 ,  where  cost  effective,  all 
Department  of  Defense  software  shall  be  written  in  the  programming  language  Ada,  in  the 
absence  of  special  exemption  by  an  official  designated  by  the  Secretary  of  Defense. 

This  congressional  action  was  motivated  by  a  belief  that  Ihere  are  still  too  many  other  languages  being 
used  in  the  DoD,  and  thus  the  cost  benefits  of  Ada  are  being  substantially  delayed”  (House  Report 
101-822). 

3.2.2.  Department  of  Defense  Policy 

Department  of  Defense  policies  irrplement  the  federal  legislation  mandating  the  use  of  Ada. 

The  two  major  DoO  statements  of  policy  guidance  regarding  the  use  of  Ada  are  found  in: 

1 .  DoD  Instruction  5000.2  [1991]  •  Defense  Acqui^tion  Management  Policies  and  Procedures 
[79] 

2.  DoD  Directive  3405.1  [1987]  -  Computer  Programming  Language  Policy  [77] 

DoD  Instruction  5000.2  P9]  requires  that: 

Ada  is  the  only  pi^ramming  language  to  be  used  in  new  defense  systems  and  major  software 
upgrades’®  of  existing  systems. 


’’Although  the  ISO  standard  was  approved  in  1987,  the  existing  Ada  language  is  called  Ada  83.  at  least  in  the  United  States, 
because  the  ANSI  standard  [13]  was  approved  in  1983. 

”A  major  upgrade  is  defined  as  the  redesign  or  addition  of  more  than  one-third  of  the  software. 
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This  policy  establishing  Ada  as  the  only  programming  language  included: 

•  Approval  of  ATLAS  [131]  for  use  in  automatic  test  equipment. 

•  Approval  to  use  languages  other  than  Ada  for  deployment  or  software  maintenance  (but  not  for 
major  system  upgrades),  if  they  were  approved  languages  when  used  in  engineering  and 
manufacturing  development. 

•  A  preference  (but  not  a  requirement)  for  Ada  in  commercial,  off-the-shelf  (COTS)  applications 
procured  for  use  by  the  DoD. 

•  The  requirement  that  only  validated  Ada  compilers  be  used. 

DoD  Directive  3405.1  defines  as  Department  of  Defense  (DoD)  policy  the  use  of  *rTK)dem  software  con¬ 
cepts,  advanced  software  technology,  software  iife-cyde  support  tools,  arxt  starxlard  programming  lan¬ 
guages.”  It  defines  DoD  policy  to  transition  to  the  use  of  Ada  to  limit  the  number  of  programming  lan¬ 
guages  used  within  the  Department  of  Defense.  This  policy  also  declares  the  DoD  intent  to  ’reduce 
software  obsolescence  and  the  cost  of  software  maintenance  through  the  use  of  approved  programming 
languages  and  appropriate  advanced  software  technology  during  all  phases  of  the  software  life  cycle.” 

This  directive  defines  Ada  as: 

the  single,  common,  computer  programming  language  for  Defense  computer  resources  used 
in  intelligence  systems,  for  the  command  and  control  of  military  forces,  or  as  an  integral  part  of 
a  weapon  system.” 

According  to  the  directive,  Ada  will  also  be  used  for  all  other  applications,  except  when  the  use  of  another 
DoD-approved  high-order  programming  language  (HOL)  is  shown  to  be  more  cost  effective  in  a  Iife-cyde 
cost  analysis.  In  fad,  the  diredive  defines  a  hierarchical  preference  for  the  use  of  software  technology  to 
meet  fundional  requirements,  based  on  an  analysis  of  Iife-cyde  costs  and  impads.  These  preferences 
are  (in  order  of  preference): 

1 .  Off-the-shelf  application  packages  and  advanced  software  technology 

2.  Ada-based  software  and  tools 

3.  Other  approved  standard  HOLs 

This  diredive  defines  a  waiver  mechanism  for  systems  or  subsystems  that  cannot  comply  with  the  pro¬ 
gramming  language  requirements  of  the  policy.  Each  waiver  request  must  address  these  fadors: 

•  life-cycle  cost  analysis 

•  risk  analysis,  addressing  both: 

•  technical  performance  risks 

•  schedule  impad 

3.2.3.  Service  Policies 

DoD  policies  on  Ada  use  are  reflected  In  the  policies  of  each  of  the  services. 

Each  of  the  services  (and  their  subunits)  has  developed  implementing  policies  regarding  the  use  of  Ada 
within  their  service.  These  are  the: 

•  Army  Implementation  of  the  Ada  Programming  Language  [83] 

•  Navy  Interim  Policy  on  Ada  [84] 

•  Marine  Corps  Ada  Implementation  Plan  [85] 

•  Air  Force  Interpretation  of  FY 1991  DoD  Appropriations  Act  [70] 
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3.2.4.  Other  Policies  on  Ada  Use 

Numerous  governmental  agencies  have  defined  policies  regarding  Ada's  use. 

Ada  has  been  a  NATO  standard  for  several  years.  And  in  the  civilian  sector,  the  Federal  Aviation  Ad¬ 
ministration,  in  its  Software  Procedures,  has  selected  Ada  as  the  single,  common,  high-order  progranr- 
ming  language  used  in  the  National  Airspace  System  (NAS)  [86].  Although  there  is  currently  no  NASA¬ 
wide  requirement  to  use  Ada,  the  NASA  Space  Station  Freedom  Project  is  currently  required  to  use  Ada 


3.3.  Ada  Benefits 

Ada's  major  advantage  is  in  providing  the  means  to  achieve  the  benefits  of  modem  software 
engineering  methods. 

Ada  was  designed  to  address  increasingly  serious  problems  in  development  and  post-deployment  sup¬ 
port  of  mission-critical  systems  by: 

•  Standardization:  Reduce  the  number  of  OoD  programming  languages  (estimated  in  the  early 
1970s  at  between  300  and  1000).^^  Ada  is  a  now  a  DoD,  FIPS,  ANSI,  ISO,  and  NATO  standard, 
among  others. 

•  Discipline:  Encourage  the  use  of  modem  software  development  methods. 

In  a  word,  cost  is  why  Ada  was  developed:  to  address  increasing  costs  due  to  use  of  multiple  languages 
and  old  languages  and  technologies.  Ada  was  designed  with  three  overriding  concerns  in  mind:  program 
reliability  and  maintenance,  programming  as  a  human  activity,  and  efficiency  [13].  By  addressing  these 
concerns,  Ada  offers  potential  solutions  to  many  software  development  problems. 

The  following  benefits  become  more  important  with  increasing  project  size: 

•  Reuse:  Ada's  constructs  and  features  are  particular^  well  suited  for  the  development  of  reus¬ 
able  components  and  subsystems.  Ada's  software  rTKXiules  can  be  made  generic  to  maximize 
reusability. 

•  Code  portability:  Ada  makes  it  easier  tor  move  source  code  between  different  computers  with  a 
minimum  of  changes  (often  referred  to  as  machine  independence).  This  can  be  a  real  issue  in 
maintaining  systems  with  long  lifetimes. 

•  People  portability:  With  language  standardization,  software  personnel  will  be  more  able  to 
move  from  project  to  project  with  significantly  less  need  to  learn  a  new  language.  (While  Ada  is 
standardized,  differences  among  compiler  and  tool  irrplementations  still  exist.)  Additionally,  with 
time,  there  should  be  a  larger  pool  of  people  able  to  work  on  any  given  project. 

•  Maintainability:  Ada  can  reduce  costs  to  make  modifications,  enhancements,  and  upgrades  in 
software. 

•  Reliability:  Ada  can  reduce  errors  during  developmerrt  and  maintenance  activities  by  providirrg 
earlier  identification  of  certain  types  of  programming  errors.  Such  capabilities  will  help  increase 
system  reliability. 


DoD  nwved  toward  language  and  processor  standardization  when  there  were  more  than  300  different  computer  program¬ 
ming  languages  and  more  than  1000  dialecis  in  use  on  DoD  systems,  as  well  as  perhaps  hundreds  of  target  processors.  This 
created  an  N  x  M  (languages  x  processors)  problem  of  enormous  proportion,  as  the  system  development  and  post-deployment 
software  support  (PDSS)  costs  of  this  situation  in  terms  of  tools,  people,  training,  and  maintenance  rapidly  escalated. 
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•  Common  basis  for  tools  and  msthodologles;  Ada  is  serving  as  a  focal  point  for  investing  in 
and  developing  high-quality  tools  and  methodologies.  Previously,  tool  and  methodology 
development  efforts  were  diffused  across  many  languages,  resulting  in  less  capable  and  lower 
quality  tools. 

•  Managing  complexity  and  modularity:  Complexity  has  become  a  major  factor  limiting 
progress  in  the  software  industry.  Ada  helps  manage  complexity  by  explicitly  supporting  the 
process  of  dividing  a  problem  into  well-understood  pieces  whose  interfaces  and  interactions  with 
other  software  and  hardware  components  are  well  defined.  This  support  is  critical  because,  in 
general,  the  approaches,  techniques,  and  languages  that  have  historically  been  used  to  build 
software  systems  do  not  address  larger  problems  very  well.  Ada  is  therefore  becoming  a  neces¬ 
sity  for  large  systems  to  function  correctly  and  reliably.  It  a  tool  that  was  designed  to  support  the 
complexity  and  versatility  required. 

•  Managernem  visibility,  more  emphasis  on  a  system  view:  Ada’s  features  encourage  a  more 
disciplined  approach  to  defining  interfaces  arrd  making  design  decisions;  hence,  managers  have 
the  opportunity  to  better  understand  and  control  their  progress  against  schedule. 

•  Productivity:  After  experiencing  a  productivity  loss  during  initial  Ada  projects,  organizations  that 
have  adopt^  Ada  report  average  productivity  gains  of  20%  after  Ada  adoption  [193]. 

While  the  potential  advantages  of  using  Ada  are  great,  its  mere  presence  and  supporting  technology  do 
not  guarantee  success.  Achieving  Ada's  benefits  means  investing  in  training,  tool  development,  pilot 
projects,  and  development  standards  to  achieve  the  resulting  benefits  over  the  entire  system  life  cycle. 

Will  Ada  save  the  DoD  money?  Savings  could  be  made  by  the  DoD  overall  in: 

•  Anticipated  cost  reductions  due  to  the  aggregate  use  of  a  single  modem,  high-order  language. 

•  Anticipated  benefits  through  standardization  and  more  up-to-date  tools/management  procedures. 

•  Possft>le  amortized  costs  due  to  software  reuse. 

An  individual  DoO  program  manager  looking  only  at  development  costs  may  recognize  that  individual 
programs  may  Incur  some  one-time  start-up  costs;  for  example.  In  acquiring  software  tools,  training,  and 
development  hardware.  However,  these  costs  may  possibly  be  amortized  across  programs  through  stan¬ 
dardization.  Taking  a  life-cycle  perspective,  a  DoD  program  manager  should  expect  the  use  of  Ada  to 
reduce  individual  program  development  and  maintenance  costs  in  the  long  run.  This  perspective  is 
crucial,  as  post-deployment  software  support  (PDSS)  is  perhaps  the  most  rapidly  growing  segment  of  the 
DoD  software  workload  [207]. 

Ada’s  importance  in  supporting  software  engineering  has  also  been  recognized  outside  the  DoD.  Ada 
has  achieved  market  acceptance  in  certain  civilian  application  domains  (e.g.,  air  traffic  control,  commer¬ 
cial  avionics,  and  space  applications);  It  is  also  being  used  in  a  selected  nuntt>er  of  other  commercial 
developments.  Commitments  to  use  Ada  in  commercial  developments  have  been  made  by  companies 
such  as  IBM,  Weirton  Steel,  Shell  Oil,  Wells  Fargo  Bank,  Motorola,  and  Boeing  Commercial  Airplane 
Company  in  the  United  States,  Nippon  Telephone  and  Telegraph  in  Japan,  and  Thomson-CSF, 
BOFORS,  Philips,  Nokia,  arxl  Volvo  in  Europe.  These  companies  have  chosen  Ada  because  they  are 
convinced  that  the  technology  is  mature  enough  for  their  applications  (which  include  communications. 


’*The  system  life  cyde  is  the  span  of  tinte  over  which  a  system  is  in  existence,  starting  with  its  conception  r*'.d  ending  with  its  last 
use.  System  life  cycim  are  usually  divided  into  conceptual,  developmental,  production,  and  operatkxrai  phases,  and  span  many 
years. 
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manufacturing,  air  traffic  control,  defense  systems,  banking,  and  teleprocessing)  and  the  advantages  are 
worth  pursuing.  In  fact,  foreign  usage  of  Ada  is  growing  faster  than  domestic  usage  [136].  Ada  is  not  just 
a  DoD  language.  Its  success  is  important  to  private  companies  as  well,  and  the  DoD  can  share  in  the 
benefits  of  commercial  interest  and  development. 

However,  it  takes  management  action,  not  just  mandates,  to  reap  the  benefits  of  Ada.  Managers  have 
found  that  through  careful  management  attention,  they  can  go  beyond  the  minimal  rewards  of  mere  policy 
compliance  and  reap  benefits  from  using  Ada.  The  following  chapter  addresses  these  management 
issues  in  light  of  adopting  Ada. 
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4.  Management 

The  transition  to  Ada  shouid  be  accompanied  by  adoption  of  other  software  engineering  tech- 
noiogies,  methods,  and  toois.  Consequently,  the  costs  of  transitioning  to  Ada  may  appear  to 
be  higher  than  ffie  costs  of  transitioning  to  other  languages  in  the  past. 

Size  (in  lines  of  code)  and  complexity  (system  functionality  implemented)  of  many  software 
systems  has  increased  dramatically,  making  it  a  pacing  item.  These  increases  in  size  and 
complexity,  regardless  of  language  used,  deserve  management  attention. 

The  resulting  management  strategy  must  incorporate  considerations  for  software  process,  per¬ 
sonnel,  and  technologies  that  are  appropriate  for  organizations  adopting  Ada  and  software 
engineering  techniques. 

Adoption  of  Ada  may  require  adjustments  in  management  strategy.''^  Ada  has  been  called  an  "enabling 
technology”  —  a  technology  that  facilitates  or  enables  the  use  of  other  technologies.  What  Ada  has 
enabled  is  the  introduction,  in  a  more  systematic  way,  of  many  of  the  fundamentals  and  discipline  of 
software  engineering. 

Not  only  must  managers  adopt  strategies  for  dealing  with  Ada,  but  they  often  must  also  simultaneously 
Incorporate  strategies  for  Improving  the  end  result  of  the  software  engineering  processes.  For  such 
strategies  to  be  successfully  applied,  management  should  be  aware  of,  and  plan  for,  the  possibility  that 
initial  projects  using  the  new  technology  may  be  more  expensive  than  later  projects  and  may  even  be 
more  expensive  than  with  the  old  technology^  [193].  Although  these  strategies  may  address  general 
issues  relevant  to  the  introduction  of  any  new  technology  or  the  improvement  of  software  engineering 
practice,  we  will  look  at  (hem  in  the  context  of  Ada. 

Ada,  even  though  K  was  standardized  In  1983,  may  still  be  a  "new”  technology  in  many  organizations  or  in 
organizations  where  Ada  is  used  in  other  parts  of  the  organization.  Adopting  Ada  and  new  software 
engineering  practices  presents  a  number  of  choices  that  must  be  made  in  the  context  of  the  organization. 


4.1.  Management  Issues 

Management  issues  In  adopting  Ada  and  managing  Ada  projects  reflect  Ada's  impact  on  the 
software  process  (tasks  and  activities,  people,  and  tools  and  technology). 

Many  oft-revisited  software-related  problems  relate  to  management  and  not  the  technology  itself  .^1  Ada 
te  part  of  a  larger  strategy  for  Irr.oroving  software  production  and  support  capabilities;  however,  Ada  itself 
is  not  a  silver  bullet.  One  of  its  major  strengths  is  that  it  supports  the  use  of  sound  software  engineering 


section  is  not  intended  to  be  an  overview  of  managing  software  acquisition  or  software  development  Other  sources  (such 
as  (160, 198])  ^ady  provide  a  broad  coverage  of  such  topics.  This  section  is  intended  to  deal  sper^caHy  with  the  impacte  of  Ada 
and  Ada  adoption  on  management  The  general  issue  of  using  and  managing  Ada  efforts  has  been  discussed  for  some  time  (for 
example,  (173]).  But  it  is  important  to  note  that  many  of  the  concerns  cited  in  earlier  reports,  such  as  [173],  do  not  have  the  import 
that  they  had  a  few  years  ago  —  the  compilers  have  matured  and  mote  is  known  about  using  Ada. 

^Kemerer  (145)  discusses  this  phenomenon  in  the  adoption  of  CASE  tools. 

^'See  also  [68]  and  predecessor  studies  for  further  elaboration  on  this  point 
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practices;  its  successful  use  requires  an  understanding  and  appreciation  of  software  engineering  and 
project  management.  In  comparing  U.S.  software  strengths  and  weaknesses,  H  has  been  noted  that,  in 
general,  problems  are  centered  on  managerial  issues,  and  strengths  are  focused  on  tool  arxJ  technical 
staff  skills  [139].  This  is  also  true  of  Ada  efforts,  as  program  management  problems  encountered  by 
managers  of  large  Ada  software  developments  are  often  not  specific  to  the  Ada  language,  but  are  related 
to  difficulties  in  software  engineering  and  program  management  [185]. 

Large  software  systems  can  be  well  engineered  and  well  managed,  aruJ  Ada  has  shown  that  it  can  help. 
Like  any  technology,  Ada: 

•  has  up-front  costs 

•  requires  educated  and  trained  professionals 

•  yields  real  benefits  when  intelligently  applied 

In  adopting  Ada  (or  any  new  technology),  managers  must  be  aware  that  the  technology  is  not  only  new, 
but  has  the  potential  for  enabling  changes  and  improvements  in  the  organization  and  its  software 
process;  specifically  in  the  tasks  and  activities  performed  (Section  4.1 .1),  the  people  who  manage  and 
develop  software  (Section  4.1 .2),  and  the  tools  used  (Section  4.1.3).  These  relationships  are  depicted  in 
Figure  4-1  below. 

4.1.1.  Software  Tasks  and  Activities 

An  organization's  defined  software  process  is  the  basis  tor  managing  its  software  tasks  and 
activities. 

Fundamental  problems  in  software  engineering  today  involve  an  inability  to  manage  the  ever-increasing 
complexity  of  software  systems  and  the  lack  of  a  discif^ined  engineering  approach.^^  A  consequence  of 
this  is  the  need  to  understand  normal  corporate  capability  and  capacHy.  This  is  true  not  only  of  defense- 
related  software  engineering.  Similar  problems  are  affecting  the  latest  generations  of  personal  computer 
(i.e.,  mass  market)  software  [200].  These  issues  can  occur  whenever  the  size  and  complexity  of  the 
systems  being  built  exceed  the  abilities  of  one  or  two  people  to  have  intellectual  control.  In  essence,  this 
is  where  software  engineering  "in  toe  large"  oomes  into  play. 

If  Ada  supports  good  software  engineering  practices  (or  is  adopted  with,  or  encourages  the  use  of,  such 
practices),  part  of  the  difficulty  in  quantifying  the  impact  of  the  language  is  that  Ada’s  impact  is  intertwined 
with  the  improvements  brought  about  by  the  use  of  these  modem  practices.  Transition  and  start-up  costs 
are  also  intermingled  with  the  ongoing  costs  of  doing  business  (at  least  for  the  first  few  Ada  projects). 
Many  firms  and  acquisition  organizations  have  an  inadequate  collection  of  prior  cost,  quality,  or  produc¬ 
tivity  data  to  compare  against  actual  results  from  new  projects  using  Ada. 

Characterizations  of  the  state  of  the  practice  of  software  engineering  have  indicated  that  many  software 
organizations  are  operating  at  an  immature  level  of  software  process  maturity  [147, 126].  According  to 
the  SEI  five-level  process  maturity  model,  current  software  engineering  practice  is  largely  at  the  initial 


^In  thinking  about  a  disciplined  engineering  approach,  a  comparison  to  bridge-building  is  a  good  one.  That  activity  has 
well-determined  techniques  for  soil  characteristics  analysis,  cost  estimation  procedures,  known  formulas,  and  generally  assumed 
reliability  of  both  process  and  product.  A  similar  domain  knowledge  base  generally  does  not  yet  universally  exist  tor  engineering 
software  systems. 
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Figure  4-1 :  Potential  Infhiences  of  Ada  Adoption 

(level  1 ,  or  lowest)  level  of  maturity.  Only  a  small  number  of  organizations  have  repeatable  (level  2)  or 
defined  (level  3)  processes  [147, 126, 229, 127]. 

Nearly  all  level  1  software  organizations  urgently  need  to  improve  their  management  systems  for  controll¬ 
ing  their  software  engineering  efforts  [126].  These  organizations  need  improvements  in  conducting 
project  reviews,  measuring  and  examining  key  indicators  of  engineering  progress,  arxJ  applying  basic 
management  methods  and  techniques.  Level  2  organizations  were  found  to  typically  have  their  costs  and 
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schedules  under  reasonable  control,  but  not  to  have  orderly  methods  in  place  for  monitoring,  controlling, 
and  improving  the  quality  of  their  software  or  the  software  processes  that  they  use  [126], 

However,  many  of  these  organizations  have  begun  steps  toward  long-term  improvement;  Hughes  has 
reported  an  almost  ten-fold  return  on  investment  from  these  efforts  [127],  One  such  step  is  the  establish¬ 
ment  of  a  software  engineering  process  group  (SEPG),  a  group  of  software  professionals  specifically 
chartered  to  focus  on  software  process  improvement.^  In  addition  to  focusing  on  software  process 
improvement  [146],  this  group  can  facilitate  the  mapping  of  generic  improvements  in  technology, 
processes,  tools,  methods,  or  environments  into  the  specific  context  of  the  organization.  Many  organiza¬ 
tions  adopting  Ada  have  used  a  similar  group  to  develop  and  spread  Ada  expertise  throughout  the 
organization.^^ 

One  of  Ada’s  design  goals  was  to  encourage  the  use  of  modem  software  development  methods,  thereby 
reducing  the  costs  and  risks  of  software  development  and  facilitating  improved  maintenance  throughout 
the  complete  software  life  cycle.  An  organization’s  successful  use  of  the  Ada  programming  language  may 
enable  that  organization  to  make  other  improvements  in  its  application  of  software  engineering  principles 
and  management  of  the  software  engineering  process  while  implementing  Ada.  Thus,  Ada  may  serve  as 
an  enabling  technology  for  broader  organizational  improvement.^ 

4.1 .1.1.  Software  Development  Process 

Ada  supports  the  development  process,  not  the  other  way  around.  In  fact,  Ada  should  be  a 
small  part  of  the  overall  process.  Using  Ada  shoukJ  not  obscure  the  fact  that  there  is  a 
specific  problem  to  be  solved,  as  systems  are  created  to  do  a  function,  not  solely  as  an 
exercise  in  af^ying  a  specific  language. 

While  serving  as  a  new  technology  that  may  enable  improvements,  Ada  must  become  an  integral  part  of 
an  organization’s  software  development  process.  This  is  true  at  all  levels  of  consideration,  from  the 
life-cycle  management  plan  [79,  Part  6,  Section  D]  defining  acquisition  strategies,  to  the  individual 
software  development  plans  for  developing  software. 

Existing  standards  [74, 75, 72]  can  be  used  with  Ada.  However,  as  with  any  DoD  standard,  tailoring  may 
be  required  for  the  particular  needs  of  any  program.  Discussion  of  some  DoD-STD-2167  and  DoD- 
STD-21 67A  related  Issues  may  be  found  In  [221 , 1 03, 1 1 6].  Significant  work  in  this  area  has  also  been 
accomplished  by  the  ACM  SIGAda  Software  Development  Standards  and  Ada  Working  Group 
(SDSAWG).  DoD-HDBK-287  P6]  and  other  documents,  such  as  [148],  have  been  developed  to  provide 
guidance  in  tailoring  DoD-STD-2167A.  Others  [120, 2]  have  suggested  tailorings  appropriate  for  object- 
oriented  techniques. 


^^See  [110]  for  mors  information  on  establishing  a  software  ertgineeiing  process  group  and  related  software  ertgineering  process 
improvement  functions. 

^See  (209,  pp.  43-44]  for  a  representative  set  of  responsibilities  for  an  Ada-focused  support  group. 

^A  broader  decussion  of  such  an  improvement  frameworK  using  Ada  as  an  enabling  technology  can  be  found  in  [119]. 
Numerous  lessons  learned  that  are  relevant  to  understanding  the  adoption  of  Ada  (32,  208],  introduction  of  related  software 
engineering  technologies  (32, 124],  or  software  process  assessment  as  a  starling  point  for  continuous  improvement  (146]  can 
provide  insight  when  planning  improvement  efforts  using  Ada  as  an  enabling  technology. 
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DOD-STD-2167A  specifies  a  set  of  activities  that  must  take  piace  during  a  software  development  project, 
and  states  that:  1 )  it  is  not  intended  to  specify  or  discourage  the  use  of  any  particular  software  develop¬ 
ment  method,  and  2)  the  contractor  is  responsible  for  selecting  software  development  methods  that  best 
support  the  achievement  of  contract  requirements.  This  standard  can  also  be  tailored  to  match  the 
planned  efforts.  For  example,  strategic  defense  system  (SDS)  software  development  has  addressed  this 
issue  in  light  of  selected  life-cycle  approaches,  and  have  developed  a  set  of  guidelines  for  tailoring  OoO- 
STD-2167A  for  SDS  software  development  [148].  Other  efforts  [130, 222]  define  the  processes  and  prac¬ 
tices  that  are  necessary  for  successful  software  development.  For  example,  IEEE  STD  1 074  emphasizes 
the  software  processes  themselves,  rather  than  the  time-sequencing  of  those  processes. 

It  is  incumbent  on  each  development  organization,  as  a  rK)rmal  part  of  software  development,  to  select 
and  follow  an  appropriate  life-cycle  model.  The  most  common  problem  in  federal  information  technology 
efforts  has  been  inadequate  management  of  the  development  life  cycle  [112].  The  software  processes 
(such  as  those  described  in  2167A  or  the  IEEE  standard)  and  the  activities  that  comprise  those  processes 
must  be  mapped  into  and  managed  as  part  of  the  selected  life-cycle  model,  regardless  of  which  model 
the  selected  model  is  based  on.^ 

In  performing  this  planning,  compatibility  with  the  developer’s  existing  methods,  toois,  and  capabiiities 
needs  to  be  considered,  as  well  as  the  impact  of  Ada  on  the  deveiopment  process.  Not  only  should  the 
process  model  adopted  by  an  organization  be  compatible  with  its  needs  in  developing  software,  but  the 
software  engineering  practices  and  methodologies  used  shouid  support  the  adopted  process  model. 

4.1 .1.2.  Ada’s  Impact  on  the  Software  Development  Process 

Ada  alone  will  not  solve  all  software  management  problems.  But,  Ada  has  been  shown  to 
have  an  impact  on  the  software  development  process  and  on  the  resulting  products. 

Most  of  the  problems  encountered  by  Ada  programs  are  management-related,  not  Ada-related,  problems 
[176].  In  addition,  some  problems  recur  across  many  projects,  such  as: 

•  lack  of  training  and/or  experience 

•  failure  to  employ  a  risk  engineering  approach 

•  improperly  specified  contract  requirements  for  software-related  items  and  processes 

•  inadequate  estimates  of  computational  resources  needed 

•  immaturity  of  Ada  development  tools  and  environments 

•  Insufficient  incremental  testing  discipline 

While  software  management  methods  such  as  design  walkthroughs  and  code  inspections  still  apply,  the 
levels  of  effort  and  time  associated  with  the  various  phases  of  the  software  life  cycle  change  somewhat 
with  the  introduction  of  Ada.  Experience  to  date  indicates  the  need  to  spend  more  time  in  the  definition 
and  design  phases  and  iess  time  in  testing  and  integration  than  was  spent  in  previous  efforts.  This  is 
probabiy  because  Ada  enforces  strict  adherence  to  certain  software  engineering  practices,  resulting  in 
more  up-front  analysis  and  design.  This  is  offset  by  fewer  programming  changes  prior  to  customer 
acceptance  and  easier  maintenance  throughout  the  life  of  the  program.  Some  Ada  efforts,  such  as  the  air 
traffic  control  efforts  for  the  FAA,  have  experienced  increased  effort  and  resources  during  the  design 


“Life-cycle  models  include;  waterfell  model  (196);  spiral  model  [35);  sottware-first  life  cycle  (128);  risk-driven  process  model 
(161);  Incremental  (or  evolutionary)  development  (1 , 69. 42. 164);  and  the  Ada  Process  Model  [195]. 
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phase  (50%  to  CDR)  [175].  Increased  emphasis  on  the  design  phase,  caused  in  part  by  increased 
emphasis  on  software  engineering,  wiii  lessen  the  time  invoived  in  testing  and  integration,  since  many 
errors  wiii  be  identified  early  In  the  development  [24, 29],  and  may  also  decrease  the  time  required  in  the 
coding  phases  [175, 193]. 

Some  rules  of  thumb  to  use  regarding  levels  of  effort  are: 

Phase  Other  Ada 

Languages 

Design  40%  50%  + 

Code  20%  l5%-30% 

Test  and  Integration  40%  20%-35% 

In  understanding  these  rules  of  thumb,  it  is  important  to  note  that  NASA’s  experience  [167]  indicates  that 
although  the  major  milestones  indicating  phases  (such  as  CDR)  changed,  the  distribution  of  effort  by 
activity  (design,  code,  test)  across  the  phases  was  quite  similar  in  both  Ada  and  FORTRAN  efforts.  This 
shows  that  software  development  tasks  or  activities  changed  little  using  Ada,  but  the  processes  for  con¬ 
trolling  and  managing  those  tasks  (as  indicated  by  phases  of  the  development  life  cycle)  were  modified  as 
a  result  of  using  Ada. 

Ada's  impact  during  development  has  been  perceived  by  many  to  cause  more  up-front  design  effort.  This 
is  not  so  much  an  impact  of  the  language  itself,  as  it  is  the  impact  of  more  software  engineering  efforts 
being  applied  early  in  the  life  cycle.  For  example,  projects  have  shifted  effort  into  design  from  later 
stages,  such  as  testing  [29].  They  spent  more  time  defining  requirements,  writing  test  documentation  and 
user  manuals  earty,  but  found  savings  in  test  and  integration.  From  studies  of  implementing  a  spacecraft 
flight  dynamics  simulator  in  FORTRAN,  and  in  parallel  in  Ada,  NASA  discovered  that  a  higher  percentage 
of  errors  was  discovered  in  the  Ada  project  during  the  implementation  phase  than  in  the  FORTRAN 
project,  i.e.,  more  errors  were  found  earlier  (when  cost  to  correct  is  lower)  [1 13]  and  the  Ada  code  had 
somewhat  fewer  interface  errors  [167]. 

Other  lessons  learned  from  Ada  experiences  are  that  more  computer  resources  are  needed,  both  host 
and  target,  and  that  configuration  management  with  Ada  is  more  technically  demanding,  because  of  the 
extra  complexity  added  by  integrating  Ada  program  libraries  with  existing  configuration  management  prac¬ 
tices. 

Cost  and  schedule  are  driven  more  strongly  by  product  characteristics  and  developer  practices  than  by 
develojsment  languages,  although  different  languages  may  have  differing  support  environments  and 
productivity  characteristics.  Factors  that  have  been  identified  as  having  an  impact  on  the  cost  of  an  Ada 
project  [135, 142]  include: 

•  Project  factors: 

•  system  architecture 

•  complexity  of  organizational  interfaces 

•  required  development  schedule 

•  resource  availability 

•  security  requirements 
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•  Process  fsctors: 


•  allocation  of  effort/costs  to  life-cycle  phases 

•  degree  of  standardization 

•  scope  of  support 

•  use  of  modem  software  methods/practices 

•  use  of  peer  reviews 

•  use  of  software  tools/environments 

•  stability  of  software  tools/environment 

•  Product  factors: 

•  product  complexity 

•  requirements  volatility 

•  degree  of  optimization 

•  degree  of  real-time  requirements 

•  degree  of  Ada  usage  (percentage  of  code  written  in  Ada) 

•  degree  of  reuse  (percentage  of  Ada  code  to  be  packaged  for  reuse  internally  and  exter¬ 
nally  to  the  project,  usage  of  reusable  software) 

■  database  size 

•  Personnel  factors: 

•  analyst  capabilities 

•  applications  experience 

•  Ada  environment  experience 

•  Ada  language  experience 

•  Ada  methodology  experience 

•  team  capabilities 

Cost  drivers  that  have  a  significant  impact  on  Ada  projects  [1 42]  are: 

•  degree  of  standardization 

•  use  of  modem  software  methods/practices 

•  use  of  software  tools/environments 

•  stability  of  software  tools/environment 

Another  key  factor  is  the  learning  curve,  reflected  in  the  experience  levels  of  the  project  team  [142], 
Although  learning  curve  effects  are  typically  overcome  after  two  to  five  Ada  projects  [193],  they  must  be 
considered  in  the  planning  of  an  organization's  adoption  of  Ada.  Such  factors  are  discussed  in  the  next 
section. 

4.1.2.  People 

An  organization’s  peopie  are  essentiai  in  impiementing  its  software  process.  Enhancement  of 
their  skiiis  shouid  be  considered  in  deveioping  management  strategies  for  adopting  Ada. 

Many  acquisition  programs  using  new  technologies  for  the  first  time  are  techrwiogy  transition  programs 
(whether  they  were  planned  that  way  or  not),  and  the  acquirers  should  expect  to  learn  along  with  the 
developers.  For  bo/h  contractor  and  customer,  implementing  a  new  techrK>logy  like  Ada  will  require  that: 

•  time  be  allocated  for  education  and  training,  and 

•  technology  experts  be  available  for  consultation  and  review. 

Very  often,  it  is  the  program  office  staff  or  the  program  manager  on  the  contractor  side  who  is  faced  with 
using  new  techmiogy.  The  good  manager  will  recognize  this  situation  and  plan  for  it  in  several  ways,  as 
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the  use  of  Ada  will  bring  with  it  a  need  for  training  (both  methodology  and  language).^^  For  a  successful 
team,  skills  must  encompass  three  critical  areas; 

1 .  Software  engineering  skills,  including  systems  analysis,  requirements  analysis,  and  design 
methodology. 

2.  Ada-specific  skills,  including  Ada  design  methodotogy  and  Ada  implementation  knowledge. 

3.  Tools  and  techniques  necessary  for  implementing  specific  design  methodologies  [181]. 

Management  may  also  need  training  in  the  selected  Ada  design  methodology  [1 68).  Existing  expec¬ 
tations  about  development  efforts  and  applying  standards,  especially  those  that  are  rooted  in  an 
organization’s  historical  use  of  another  language  or  another  methodology,  may  be  incompatible  with  Ada 
technology  [168]. 

4.1.3.  Tools  and  Technology 

There  are  technical  issues  associated  with  the  adoption  of  Ada  and  Ada  tools  as  with  the 
adoption  of  almost  any  technology.  Software  development  tools  ami  their  use  should  reach  a 
level  of  maturity  before  being  used  extensively  in  production. 

Tools  are  valuable  aids  for  increasing  productivity  and  improving  software  quality.  Software  tools,  includ¬ 
ing  compilers  and  CASE  tools,  have  a  development  life  cycle  very  similar  to  the  life  cycle  of  other 
software: 

•  requirements  development 

•  design 

•  product  development 

•  in-house  (or  alpha)  testing 

•  beta  testing^* 

•  initial  delivery 

•  continued  refinement 

•  production  quality 

•  maturity 

•  obsolescence 

The  maturation  process  from  initial  delivery  to  production  quality  is  a  key  period  and  can  take  significant 
time.  Immature  tools  Oust  out  of  development)  can  have  a  negative  impact  on  productivity  if  software 
developers  must  concurrently  debug  new  applications  software,  new  tools,  and  new  hardware.  Often  new 
tools  are  abandoned  because  they  are  not  understood  or  they  fall  short  of  expectations.  Program 
managers  should  allow  time  in  program  schedules  for  learning  how  to  use  a  new  tool,  developing 
proficiency,  and  discovering  and  correcting  problems  and  limitations. 

Some  of  Ada’s  early  implementations  were  not  sufficiently  efficient  for  specific  applications.  However,  this 
has  changed  with  the  maturation  of  compilers  and  tools;  today,  many  large  systems  would  be  worse  off 
without  Ada.  The  Ada  language  itself  has  facilities  for  handling  complexity;  however,  one  must  trade  off 
front-end  costs  versus  life-cycle  costs,  such  as  host  machine  resources  arxJ  necessary  tools  and  com¬ 
pilers. 


^See  Section  5  for  more  on  the  subject  of  learning  Ada 

^Beta  testing  is  a  limited,  constrained  tsst/evaluation  performed  very  dose  to  final  completion  of  a  product  for  the  purposes  of 
getting  user  reaction  and  finding  additional  bugs.  It  is  usually  performed  outside  the  development  group. 
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Ada  facilitates  (rather  than  enforces)  the  application  of  software  engineering  discipline.  Ada  has  facilities 
that  allow  explicit  use  of  modem  software  engineering  techniques,  including  modularity,  information 
hiding,  data  abstraction,  and  object  orientation  (to  a  limited  point).  It  is  still  possible  to  write  poor  code, 
and  Ada  can  be  (and  has  been)  used  as  a  scapegoat  for  poorly  developed  and  poorly  managed  system 
development  efforts.  However,  to  gain  many  of  the  benefits  that  Ada  facilitates,  not  only  do  they  have  to 
be  used  correctly  by  the  practitioners  who  build  the  software,  but  the  computer  resources  on  the  host 
computer  (memory,  processor  cycles)  and  development  tools  may  be  more  costly  overall  than  typically 
needed  for  other  programming  languages.  Ada  compilers  do  more  work,  in  checking  interfaces  or  in 
separate  compilation,  for  example,  than  do  many  other  language  compilers,  and  thus  require  more 
resources.  The  belief  is  that  overall  life-cycle  costs  will  be  lower;  this  up-front  investment  will  save  much 
more  than  it  costs  in  the  long  run.  As  there  is  not  yet  sufficient  experience  in  maintaining  numerous  Ada 
systems,  this  is  largely  conjecture;  data  over  a  3  - 10  year  period  are  needed  before  conjecture  about 
maintaining  large  systems  can  be  confirmed  (or  denied!). 

Throughout  procurement  (and  operational  upgrades),  it  is  important  to  assess  the  applicability  of  Ada  to  a 
system.  If  a  subsystem  is  to  be  upgraded  and  the  interfaces  are  not  clean,  nor  can  they  be  made  clean  in 
a  cost-effective  manner,  maybe  Ada  is  not  the  right  choice.  And,  if  the  system  is  identified  as  resource- 
constrained,  an  assessment  of  the  system  to  identify  those  pieces  that  really  are  resource-critical  can 
assist  in  isolating  them  neatly,  and  provide  risk  identification  of  those  pieces  where  additional  managerial 
and  technical  attention  is  applicable. 

The  goals  of  a  program  manager  are  not  to  make  use  of  Ada  (or  any  new  technology),  but  are  larger;  to 
produce  the  specified  system  on  time,  within  budget,  usable  and  maintainable  over  the  projected  life 
cycle,  arxl  within  the  projected  scope  of  the  system. 

4.2.  Adopting  New  Technology 

4.2.1.  A  Model  of  Technology  Development  and  Insertion 

Any  new  technology  goes  through  a  readily  idenVflable  process  of  development  and  matura- 
Uon.  The  Ada  language  and  its  supporting  technology  are  following  this  same  process.  Few 
adoption  issues  are  unique  to  Ada.  Many  are  simply  issues  associated  with  using  any  new 
technoiogy. 

Many  of  the  issues  that  are  raised  regarding  the  adoption  of  Ada  are  generic  concerns  encountered  when 
introducing  any  new  technology  [27].  Moreover,  most  issues  relating  to  programming  languages  can  be 
generalized  to  more  than  just  Ada. 

The  process  of  technology  development  in  both  hardware  and  software  generally  includes  the  following 
phases: 

•  identification  of  problem  or  need 

•  development  and  insertion  of  initial  product  solution 

•  iteration: 

•  use 

•  feedback 

•  refinement 

•  maturity 
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Ada  is  generally  following  this  model  and  is  now  in  the  latter  phases  of  the  product  use,  feedback,  and 
refinement  iteration;  the  approval  of  the  Ada  9X  standard  will  signal  a  major  milestone  in  refinement 
efforts. 

Adoption  of  new  hardware  technology  has  often  been  faster  and  smoother  than  adoption  of  software 
innovations.  This  may  be  because  hardware  is  tangible,  while  software  is  abstract  and  intangible.  Per¬ 
haps  because  of  this,  introduction  of  software  technologies,  including  Ada,  suffer  from  a  very  high  degree 
of  inertia.  Since  introduction  of  new  technology  requires  change,  and  human  beings  are,  by  nature, 
conservative,  it  almost  always  takes  a  certain  minimal  amount  of  time  before  new  technology  can  actually 
be  introduced  into  the  workplace. 

The  use  of  Ada  and  supporting  methodologies,  once  demonstrated  on  a  “rear  project,  can  not  only  serve 
as  a  catalyst  for  the  introduction  of  Ada,  but  also  for  other  new  methods,  tools,  or  techniques  [119].  Ada 
has  been  called  an  'enabling  technology”  —  a  techrtology  that  facilitates  the  use  of  other  technologies. 
For  example,  Ada  enables  building  very  portable  software.  Ada  also  enables  writing  very  low-level, 
machine-dependent  software.  Both  capabilities  can  be  necessary.  If  bits  have  to  be  packed  into  a 
hardware-defined  message  packet  and  the  operating  system  used  to  transmit  the  packet  over  a  specified 
standard  bus,  then  non-portable  code  may  be  needed,  and  Ada  will  allow  that.  At  the  same  time,  Ada 
supports  writing  code  that  is  very  portable. 

In  understanding  software  technology  adoption,  two  key  points  stand  out  [45]: 

1 .  The  transfer  of  a  technology  to  an  organization  without  the  maturity  to  understand,  absorb, 
and  apply  it  is  likely  to  cause  problems,  rather  than  to  improve  that  organization’s 
capabilities.^ 

2.  The  process  of  software  technology  transfer  is  complex,  and  it  involves  many  roles  and 
phases. 

A  generic  model  of  technology  transition,  such  as  that  in  Figure  4-2,  shows  that  technology  adoption  is  a 
phased  activity  that  moves  an  organization  through  a  sequence  of  transition  stages  for  a  given 
technology.  When  attempting  to  introduce  a  new  technology,  target  audiences  within  that  organization 
pass  through  different  levels  of  commitmentto  the  technology  [158].  The  early  stages  {contact, 
awareness,  and  understanding  focus  on  the  acquisition  and  comprehension  of  information  about  the 
technology;  the  later  stages  {trial  use  and  adoption)  focus  on  relative  commitment  to  actual  use  of  the 
technology,  leading  to  institutionalization  or  widespread  use  of  the  technology  throughout  the  organiza¬ 
tion.  Transition  is  successful  when  the  target  audience  reaches  the  stage  of  commitment  appropriate  for 
that  technology  in  their  organization. 

When  adopting  a  new  technology,  more  than  just  the  technological  factors  must  be  taken  into  account. 
Cultural  resistance  and  difficulties  must  also  be  overcome.  As  noted  in  Figure  4-2,  moving  through  the 
stages  of  adoption  requires  increasing  levels  of  commitment  throughout  the  organization,  not  just  from 
individuals.  The  cultural  barriers  can  be  pathological;  people  do  not  like  to  change.  So  transition  to  any 
new  technology,  including  Ada,  must  also  address  the  human  issues,  the  organizational  issues,  arxJ  the 
process  issues. 


^^See  [1 1 7]  for  an  interesting  analysis  of  how  this  has  happened  writh  Ada  and  the  U.S.  Air  Force. 
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Figure  4*2:  Stages  of  Adoption  of  New  Technology 


How  does  this  affect  managers?  Certainly,  a  program  manager  may  witness  some  resistance  in  dealing 
with  developers;  more  than  likely,  their  own  organization  will  go  through  many  of  the  same  changes  itself. 
Ada  (a  "product  technology")  often  brings  along  with  it  other  "process  technologies,"  such  as  more 
modem  software  engineering  discipiine  or  toois  to  support  that  discipline.  Process  technologies  Invariably 
affect  organizational  ways  of  doing  business,  so  plan  on  changes  occurring. 

Ada  adoption  across  the  community  is  at  the  institutionalization  stage  in  Figure  4-2;  however,  individuals 
and  organizations  may  just  be  starting  to  move  up  this  cunre  and  address  the  issues  of  Ada  use. 

4.2.2.  Inhibitors  to  the  Widespread  Use  of  Ada 

As  use  of  Ada  has  progressed  through  this  process  of  development  and  maturation,  numerous 
inhibitors  have  slowed  the  widespread  use  of  Ada.  These  inhibitors  can  be  overcome  and 
planned  for  in  adopting  Ada. 

Inhibitors  to  innovation  and  adoption  of  new  technologies  stem  from  both  a  lack  of  awareness  and  an 
inability  to  assimilate  the  new  technology  into  an  organization  and  its  capabilities  [45].  Redwine  et  al. 
[190]  discuss  some  of  the  inhibitors  to  software  technology  transition.  Examples  of  these  encountered  in 
the  adoption  of  Ada  are  described  in  [117]. 

Inhibitors  to  Ada  adoption  address  many  managemertt  arxf  technical  issues,  as  well  as  many  myths  that 
developed  as  a  result  of  early  Ada  efforts.  Many  of  the  inhibitors  are  not  real  but  only  perceived  and  can 
be  overcome  with  proper  planning  and  management.  The  following  inhibitors  are  encountered  specifically 
in  using  Ada. 
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Compll«r  availability:  Although  Ada  compilers  are  not  available  for  every  computer,  most  major  proces¬ 
sors  in  use  today,  ranging  from  specialized  DSP  processors  to  microprocessors  to  mainframe  computers, 
have  Ada  compilers.  There  are  501  total  validated  Ada  compilers  listed  on  the  official  AJPO  list  (as  of 
October  1992).  This  number  has  grown  from  78  validated  compilers  in  May  1987,  and  only  14  in  early 
1986.  This  listing  of  validated  compilers  is  widely  available  through  online  and  printed  sources  (see 
Appendices  A.2  and  B.3). 

Ada  and  embedded  systems:  Although  Ada's  origins  were  strongly  influenced  by  the  needs  of  the 
defense  mission-critical  computing  community,  the  Ada  language  design  team  placed  emphasis  on  sup¬ 
porting  modem  software  engineering  practices;  the  result  is  a  language  with  wide  applicability  in  develop¬ 
ing  well-engineered,  quality  software.  In  fact,  Ada  has  been  used  successfully  for  MIS/CIM 
applications  [87].  There  are  no  technical  reasons  why  Ada  cannot  be  used  successfully,  and  cost- 
effectively,  for  such  applications  [64]. 

DoD  policy  and  Ada:  Many  managers  of  DoD  software  efforts  were  not  aware  of  the  DoD  policy  on  the 
use  of  Ada  or  believed  they  were  an  exception  to  the  Ada  policy.  Current  DoD  policy  requires  that  Ada  be 
used  for  new  defense  systems  and  for  major  software  upgrades  of  existing  systems,  where  cost  effective. 
For  efforts  that  cannot  comply  with  the  policy,  a  waiver  must  be  obtained.  See  Section  3.2  for  a  brief 
description  of  the  waiver  process  for  efforts  that  cannot  comply  with  the  policy. 

New  technology:  Development  personnel  are  cost-  aixl  schedule-driven,  and  they  are  evaluated  on 
these  factors.  Using  any  new  technology  introduces  risks,  but  those  risks  can  be  managed.  Now  that  Ada 
has  matured,  the  risks  to  cost  and  schedule  from  adopting  Ada  have  been  significantly  reduced.  Recent 
studies  have  shown  that  Ada  can  be  at  least  as  cost-effective  as,  or  more  so  than,  languages  that  have 
traditionally  been  used  for  developing  large,  software-intensive  systems  [39, 193, 81]. 

Lack  of  knowledge:  A  lack  of  knowledge  in  software  engineering  and  Ada  perpetuates  inertia  and 
inappropriate  business  practices,  delaying  the  transition  to  Ada.  An  effective  training  program  is  a  key 
part  of  developing  an  organization's  software  engineering  capability,  and  is  an  area  where  many  or¬ 
ganizations  find  a  need  for  improvement  [147],  Ada  training,  supported  by  appropriate  software  engineer¬ 
ing  training,  is  available  and  can  assist  organizations  in  improving  capabilities.  Even  though  Ada  lan¬ 
guage  training  addresses  a  small  portion  of  the  knowledge  need,  software  engineering  training  (in  stan¬ 
dards,  architectures,  environments,  processes,  methods,  and  reuse)  can  greatly  contribute  to  the  im¬ 
provement  of  software  engineering  practices.  This  fact  is  often  missed  due  to  a  lack  of  understanding  of 
the  relationships  between  software  engineering  and  Ada. 

For  example,  although  software  development  standards  permit  tailoring,  the  lack  of  knowledge  to  properly 
define  such  tailoring  can  be  an  impediment  to  the  use  of  tailoring;  often  the  perceived  incompatibilities 
between  the  standards  and  usage  with  Ada  is  blamed  on  Ada.  It  is  essential,  therefore,  that  there  be 
carefully  planned  education  and  training  programs  that  teach  fundamental  software  engineering  concepts, 
design  methodologies,  and  the  effective  use  of  the  Ada  language.  Such  training  programs  can  be  tailored 
to  ensure  that  system  acquirers,  as  well  as  software  managers  and  technical  staffs,  develop  an  ap¬ 
propriate  working  knowledge  of  Ada. 

A  recent  study  of  software  technology  transition  [32]  states  that  the  Ada  champion  comes  from  the  tech¬ 
nical  staff  42%  of  the  time,  from  middle  management  36%  of  the  time,  and  from  top  management  only 
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14%  Of  the  time.  It  also  indicated  that  a  middle  management/techniral  staff  consensus  was  achieved  in 
only  about  7%  of  the  cases  for  Ada  adoption  compared  to  26%  of  the  cases  for  a  more  established 
software  technology,  such  as  structured  programming.  Another  recent  study  [232]  has  indicated  for  one 
large  organization  that  over  half  of  the  people  in  software  positions  have  had  no  Ada  education  or  train¬ 
ing.  Another  study  [205]  concluded  that  the  low  acceptance  rate  of  Ada  within  their  organization  is  due 
largely  to  the  lack  of  a  formal  education  and  training  program  affecting  all  categories  of  software  profes¬ 
sionals.  These  factors  indicate  that  a  successful  Ada  education  program  must  address  all  levels  in  an 
organization. 

DoD  procurement  process:  The  current  procurement  process  may  not  be  conducive  to  Ada  adoption 
arxl  long-term  software  engineering  improvement.  A  recent  survey  of  Ada  adoption  indicates  that  lowest 
development  cost  still  is  the  major  award  factor  on  DoD  contracts,  and  that  industry  perceives  the  DoD  as 
unwilling  to  trade  lower  life-cycle  cost  for  greater  developmerrt  cost  [49],  This  short-term  disincentive  to 
educate,  improve  the  process,  design  for  reuse,  and  engineer  for  quality  is  at  the  root  of  a  range  of 
inappropriate  business  practices  that  hamper  the  evolution  of  software  development  toward  a  tore  en¬ 
gineering  discipline.^ 

The  excessive  concern  for  lowest  development  costs  often  results  in  an  antagonistic  relationship  between 
the  contractor  and  the  customer  and  senres  as  a  disincentive  to  investment  in  start-up  costs  such  as 
training,  equipment,  tools,  and  methods.  It  can  also  result  in  unrealistic  assumptions  (particularly  at 
proposal  time)  about  cost  and  schedules  on  an  organization's  early  Ada  projects.  It  may  be  necessary  for 
the  program  managers  to  make  creative  use  of  current  procurement  practices,  such  as: 

•  Including  Ada  and  software  engineering  capabilities,  transition  activities,  or  past  performance 
(including  quality  and  reuse)  on  Ada  projects  in  the  proposal  evaluation  criteria.^^ 

•  Accounting  for  increased  development  costs  on  an  organization’s  early  Ada  projects. 

Among  defense  contractors,  Ada  capabilities  are  developed  in  earnest,  and  Ada  is  used  earlier  in  produc¬ 
ing  real  systems  when  organizations  believe  that  they  will  be  more  likely  to  get  a  government 
contract  [32].  Industry  must  be  convinced  that  the  government  is  serious  about  successfully  adopting 
Ada. 

Early  perceptions:  In  the  face  of  early  disparaging  reports  on  Ada,  there  has  been  little  advertising  of 
the  successfully  fielded  Ada  systems  (e.g.,  [87, 108, 97, 38, 94])  and  little  concerted  effort  to  gather, 
analyze,  and  distribute  objective  data  about  the  economic  impact  of  Ada  on  the  software  engineering 
discipline.  The  early  bad  press  has  left  a  legacy  because  of  the  weaknesses  of  early  implementations  and 
the  experiences  on  eariy  Ada  projects.  It  is  also  tempting  for  all  concerned  to  blame  the  failure  of  a 
project  on  a  new  technology.  Experiences  from  successful  Ada  projects  are  often  withheld  by  organiza¬ 
tions  for  reasons  of  competitive  advantage  [166]. 

Language  Issues:  Real  and  perceived  language  limitations  hampered  the  adoption  of  Ada.  The  AJPO 
has  emphasized  a  strict  validation  process  that  has  yielded  hundreds  of  validated  compilers.  Great 
progress  has  been  made  in  Ada  compiler  technology,  including  the  development  of  optimizing  compilers 


^For  further  discussion  of  these  issues,  see  (163). 

^'See  (80, 47, 82, 40, 62]  for  more  information  about  evaluating  contractor  capabilities. 
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for  many  platforms.  Clearly,  the  image  of  Ada  implementations  having  poor  performance  and  quality  is 
much  outdated. 

However,  many  projects  still  lack  the  depth  of  expertise  arxf  the  urKJerstanding  of  the  complex  interactions 
between  runtime  system  (see  Section  6.1),  language  features,  and  design  style  to  evaluate  and  select 
compilers  [226]  and  tools.  The  quality  of  compilation  systems  is  an  issue  of  compiler  evaluation;  evalua¬ 
tion  (see  Section  6.2.2),  as  well  as  validation  (see  Section  6.2.1),  should  be  emphasized. 

The  difficulties  of  interfacing  wrth  other  languages  (e.g.,  limitations  on  pragms^^  interface)  hinder  the 
introduction  of  Ada  where  a  large  body  of  reusable  software  in  other  languages  is  available.  Some 
excellent  implementation-dependent  variations  exist  but  when  used  may  limit  future  portability. 

Previous  complaints  about  the  size  and  complexity  of  Ada  have  somewhat  subsided  to  be  replaced  by 
laments  about  Ada's  lack  of  inherent  support  for  OOD,  distributed  applications,  and  formal  reasoning. 

C-H-  and  the  OSI  model  are  often  seen  as  solutions  to  OOD  and  distributed  support,  although  Ada  9X  will 
address  many  of  these  concerns.^ 

Tasking  Is  still  a  concern  for  some,  but  continuing  rurttime  performance  improvements,  Ada  9X  enhance¬ 
ments  (see  Section  9),  and  rate  monotonic  analysis  (RMA)  [204]  address  many  of  these  concerns. 
Projects  should  evaluate  Ada  implementations  in  light  of  their  specific  requirements. 

Integration  with  CASE  tools:  Current  CASE  tools  are  poorly  integrated  with  most  Ada  implementations. 
An  integrated  development  environment  should  help  enforce  some  of  the  software  engineering  discipline 
encouraged  by  Ada.  Development  of  such  environments  is  continuing  [186].  For  example,  a  standard 
binding  for  CASE  tools  interfacing  with  Ada  libraries  (Ada  Semantic  Interface  Specification  —  ASIS)  has 
been  developed  and  is  planned  for  standardization  as  an  interface  for  Ada  9X. 

4.2.3.  Adopting  Ada 

The  real  or  perceived  inhibitors  to  the  adoption  of  Ada  can  be  overcome  by  systematically 
planning  and  managing  the  process  of  learning  and  using  the  new  technology.  Certain  con¬ 
siderations  can  faa'Iitate  transition  and  mitigate  risks  in  transitioning  to  Ada. 

The  software  industry  has  been  engaged  in  Ada  transition  since  the  early  1980s.  Many  of  the  uncer¬ 
tainties  faced  by  the  early  adopters  are  better  understood  today,  including; 

•  Validated  Ada  compilers  are  generally  available  and  their  quality,  though  already  acceptable, 
continues  to  improve. 

•  Though  tools  exist,  project-selected  tools  may  not  be  integrated  into  a  software  support  environ¬ 
ment. 

•  For  certain  embedded  computer  systems,  real-time  designers  require  control  and  favor  deter¬ 
ministic  schedulers  not  available  with  Ada  tasking  [98]. 

•  Research  in  using  Ada  for  distributed  systems  is  promising  but  not  yet  demonstrated  for  some 
forms  of  distributed  systems. 


^Pragmas  ara  used  to  convey  information  to  the  compiler,  for  example,  as  an  instruction  to  the  compiler  to  perform  some  special 
action  such  as  compiler  optimization  or  to  interface  to  software  written  in  other  languages. 

^’^’See  (81 )  for  one  analysis  of  the  applicability  of  0+ -f . 
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•  To  achieve  portabifity,  projects  must  state  portability  as  a  design  objective. 

•  Training  for  Ada  programmers  is  available;  training  and  experience  for  Ada  designers  and 
managers  is  crucial. 

Managing  the  transition  to  Ada  adoption  is  an  exercise  in  risk  management,  that  is,  managing  uncertainty. 
There  may  be  uncertainty  about  the  readiness  of  an  organization  to  accept  a  commitment  to  produce 
software  products  using  Ada.  In  addition,  there  may  be  uncertainty  about  the  specific  project  needs  and 
their  interaction  with  Ada's  capabilities.  A  managenrrent  strategy  for  adopting  Ada  must  incorporate  risk 
management  strategies  to  match  an  organization's  readiness  for  Ada  with  specific  project  needs  to  iden¬ 
tify  and  resolve  any  uncertainties. 

Thus,  if  transitioning  to  Ada  is  simply  an  exercise  in  risk  management,  why  is  it  difficult?  Expertise  has 
been  identified  as  playing  a  large  role  in  the  adoption  decisions  made  by  firms  with  respect  to  Ada  [208]. 
That  study  found  that  firms  that  have  developed  greater  software  engineering  expertise  appear  to  value 
Ada  nwre,  and  expect  to  incur  fewer  costs  of  adoption.  This  expertise  or  sensitivity  to  software  engineer¬ 
ing  principles,  manifested  in  both  contractor  and  acquisition  organizations,  was  found  to  be  a  critical  factor 
in  the  adoption  of  Ada.  Developing  that  expertise,  with  Ada  and  in  the  context  of  an  organization's  current 
capabilities,  is  crucial  in  an  organization's  adoption  of  Ada. 

An  organization  planning  to  improve  its  capabilities  by  adopting  Ada  must  examine  its  current  capabilities 
and  develop  risk  management  strategies  for  dealing  with  Ada's  impacts  in  each  of  the  areas  shown  in 
Figure  4-1 :  tasks,  people,  and  tools. 

•  Tasks:  Management  tasks  must  focus  on  planning  and  controlling  costs  and  schedules,  con¬ 
figuration  management,  product  assurance,  and  measurement:  and  on  the  degree  to  which 
project  plans  and  estimation  factors  for  product  size,  productivity,  and  quality  are  Ada-sensitive. 

Methodological  concerns  deal  with  the  degree  to  which  Ada  design  methods  are  exploited  and 
how  early  in  the  life  cycle,  how  many  software  engineers  are  involved,  the  size  of  the  system  to 
be  developed,  and  the  degree  to  which  the  requirements  are  well  defined  and  understood.  Risk 
assessment  in  this  area  is  influenced  by  the  techrK>logical  expertise  of  the  organization,  the 
selected  life-cycle  riKxlel,  and  whether  systematic  approaches  are  used  for  requirements, 
design,  code,  and  test. 


•  People:  Assessment  of  personnel  capetfsility  is  determined  by  the  degree  to  which  qualified 
Ada-trained  personnel  exist.  Training  needs  are  determined  by  the  number  of  software  en¬ 
gineers  and  managers  to  be  trained  and  the  expected  knowledge  foundation  on  which  that  train¬ 
ing  is  based.  Existing  capabilities  and  training  needs  will  influence  the  training  resource  selected, 
the  extent  of  the  training,  and  the  number  of  software  engineers  and  managers  to  be  trained. 
Organizations  that  have  used  in-house  training  have  developed  their  Ada  capabilities  faster  [32]. 


•  Tools:  Selection  of  tools  can  be  very  important  in  adopting  Ada.  The  selected  and  acquired  Ada 
compiler  must  meet  the  host  and  target  needs  of  the  project  in  terms  of  the  capacity  require¬ 
ments  (time  and  space)  for  both  host  and  target  systems,  the  performance  demanded  by  the 
application  domain,  the  computer  system  architecture  selected  for  the  target  system,  and  re¬ 
quirements  for  growth  and  adaptation.  An  active  process  of  compiler  specification,  selection, 
and  acquisition  can  aid  in  this  evaluation  and  selection  (see  Section  6.2.2,  as  well  as  [226]). 

The  extent  to  which  Ada  and  CASE  tools  support  the  technical  and  management  activities  of  the 
life  cycle  and  the  degree  to  which  these  tools  operate  as  an  integrated  environment  during  both 


CMU/SEI-92-TR-29 


41 


product  creation  and  post-deployment  support  is  another  important  factor.  Each  activity  of  the 
life  cycle  must  be  assessed  for  tool  and  methodology  congmence. 


The  organization  that  wants  to  adopt  Ada  as  a  programming  language  and  recognizes  that  Ada  adoption 
must  be  managed  may  find  these  considerations  useful  in  planning  and  managing  the  transition  to  Ada. 
The  question  no  longer  is,  "Is  Ada  ready?*;  but  rather,  *How  ready  are  we  for  Ada?"  Organizatior^  that 
acquire  Ada  capabilities  and  an  Ada  compiler  early  in  this  adoption  effort  are  using  Ada  sooner  for 
production  work  [32]. 

4.3.  Managing  Ada  Adoption  Efforts 

An  organization  successfully  adopting  Ada  will  invest  in,  plan,  and  manage  Ada  adoption  ef¬ 
forts  as  it  moves  through  the  various  stages  of  adoption. 

Introducing  Ada  effectively  necessitates  that  an  up-front  investment  be  made  to  reap  longer  term  benefits. 
There  are  several  classes  of  ecorx>mlc  investments  and  cost  drivers: 

•  Compiler  and  other  tools. 

•  Hardware  testbeds. 

•  Development  hardware  costs,  as  routine  computer  facility  expenses  can  be  somewhat  higher 
than  expected  because  of  increased  compile  time  and  storage  costs. 

•  Software  development  environment  costs. 

•  Training  costs,  including  language  training,  and  training  in  new  software  engineering  practices, 
disciplines,  and  methodologies  for  management  and  software  personnel  in  developer  and  ac¬ 
quirer  organizations. 

Several  of  these  costs  are  one  time  in  nature  and  will  decrease  as  Ada  training  is  completed,  Ada  pro¬ 
gramming  environments  are  widely  installed,  as  software  tools  mature,  and  as  hardware 
cost/performance  continues  to  drop.  Although  Incurring  up-front  costs  is  acceptable,  it  presents  a  special 
problem  for  Ada  acceptance  by  program  managers  and  contractors.  The  costs  of  training,  compiler  and 
associated  tool  acquisition,  and  associated  hardware  are  real  and  readily  measured,  while  the  benefit  Is 
more  difficult  to  measure  and  will  accrue  In  the  future  over  the  life  cycle  of  the  software  arxl  subsequent 
projects.  Program  budget  and  schedule  must  reflect  the  costs  and  risks. 

Program  managers  need  to  understand  several  key  points: 

•  Education  for  software  engineering  and  software  project  management  is  required  tor  bofh  cus¬ 
tomer  and  contractor. 

•  Software  discipline  and  planning  must  be  enforced.  For  example,  the  use  of  a  common  program 
formatting  style  Is  a  simple  technique  to  improve  the  readability,  understandability,  and  main¬ 
tainability  of  the  code.  In  addition,  a  common  style  can  be  enforced  using  a  tool  known  as  a 
pretty  printer  (see  Section  6.2.2.3). 

•  Periodic  risk  assessments  should  be  planned  and  executed. 

•  Performance  issues  and  risks  should  be  addressed  (see  Section  7.4.1). 

Organizations  just  developing  Ada  capabilities  will  often  develop  their  initial  capabilities  through  training 
and  the  acquisition  of  compilers  and  tools  that  meet  project  needs.  Programmers  will  be  trained  to  design, 
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read,  and  write  Ada  programs,  and  managers  will  be  trained  to  read  Ada  designs  recorded  in  the  style  of 
the  project,  as  well  as  in  management  topics.  Perhaps  most  important  is  the  development  of  an  internal 
core  group  of  skilled  Ada  personnel. 

The  following  action  plan  is  recommended  for  sprinkling  a  larger  effort  with  personnel  drawn  from  this 
initial  core  group  of  skilled  personnel: 

•  Develop  and  execute  a  long-term,  phased  training  plan  that  includes  management,  application 
specialists,  lead  designers,  software  engineers,  and  testing  personnel.  Management  training  is  a 
must.  Course  matenai  must  include  software  engineering  principles  and  application  concepts. 

Insights  into  various  training  strategies  can  be  obtained  from  Section  5  and  [181]. 

•  Structure  the  development  schedule  to  contain  a  few  non-critical  Ada  tasks  that  can  be  ac¬ 
complished  very  early  in  the  program  (in  parallel  with  requirements  definition  and  preliminary 
design).  The  main  purpose  of  these  tasks,  which  could  be  prototypes  of  parts  of  the  system 
under  development,  is  to  develop  some  personnel  experienced  in  using  Ada.  Emphasis  should 
be  on: 

•  small  team  efforts, 

•  extensive  review  of  the  ongoing  development. 

•  document  lessons  learned  and  distribution  of  this  information,  and 

•  management  obsen/ation. 

•  Since  Ada  has  been  shown  to  change  the  levels  of  effort  applicable  to  various  phases  of  the  IHe 
cycle,  management  should  not  attempt  to  rigidly  control  the  development  of  these  tasks,  but 
rather  should  use  them  as  a  vehicle  to  understand  what  will  happen  in  the  mainline  development. 

•  Sprinkle  the  experienced  personnel  from  the  small  Ada  projects  in  as  leaders  of  the  mainline 
development  [191]. 

•  Based  on  the  results  of  the  early  Ada  tasks,  adjust  the  software  development  plan  (SOP)  and  the 
training  plan  for  the  mainline  effort. 

•  Consider  bringing  in  some  outside  experts  with  experience  developing  similar  systems  in  Ada  to 
evaluate  the  system  design  (hardware  and  software)  and  implementation  strategy. 

An  organization  that  is  institutionalizing  its  Ada  capabilities  is  able  to  make  effective  use  of  its  manage¬ 
ment  processes  and  methodology  mechanisms  to  develop  Ada  software.  The  organization  has  selected 
a  life-cycle  model,  one  that  exploits  Ada  in  the  earlier  activities  of  the  project.  For  each  activity  in  the 
selected  life  cycle,  appropriate  methods  and  tools  have  been  chosen  and  personnel  trained  in  their  use. 
Organizations  that  have  accomplished  this  will  often  look  to  other  advantages  to  be  gained  through  reuse 
or  domain  architectures. 

Gaining  the  benefits  of  software  engineering  does  not  happen  magically.  Both  the  customer  and  the 
contractor  must  be  educated  in  software  engineering  and  its  management;  both  must  be  actively 
involved  —  by  setting  a  good  example  —  in  the  application  of  sound  software  engineering  and  manage¬ 
ment  practices.  And  even  if  the  management  is  excellent  and  the  requirements  are  stable,  risk  assess¬ 
ments  (of  Ada,  of  system  requirements,  and  of  new,  upcoming  technological  solutions)  should  still  be 
done. 
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4.4.  For  More  Information  . . . 

The  resource  recommerxjations  below  are  intended  as  an  initial  starting  point  for  those  looking  for  more 
information  about  the  topics  addressed  in  this  chapter. 

Software  Process  Management 

•  Capability  Maturity  Model  tor  Software  [1 83] 

•  Key  Practices  of  the  Capability  Maturity  Model  [222] 

•  Software  Capability  Evaluation  (SCE)  Tutorial  [47] 

•  Managing  the  Software  Process  [125] 

Software  Process  Improvement 

•  Software  Process  Improvement  at  Hughes  Aircraft  [t27] 

•  Software  Engineering  Process  Group  Guide  [1 1 0] 

•  Implementing  Software  Engineering  Practices  [44] 

•  A  Guide  for  Implementing  Total  Quality  Management  [66] 

•  An  introducrion  to  the  Continuous  Improvement  Process:  Principles  and  Practices  [159] 

•  Implementing  Total  Quality  Management:  An  Overview [tZT] 

Ada  Adoption 

•  Software  Engineering  as  a  Radical  Novelty:  The  Air  Force  Ada  Experience  [117] 

•  Process  Maturity  as  a  Guide  to  Phased  Ada  Adoption  [1 72] 

•  Ada  and  Software  Management  in  NASA:  Assessment  and  Recommendations  [8] 

•  Adoption  of  Software  Engineering  Innovations  in  Organizations  [32] 

•  Understanding  the  Adoption  of  Ada  [208] 

•  Software  Technology  Transition  [158] 

•  Ada  Risk  Handbook  [21 2] 

Ada  Project  Management 

•  Department  of  the  Navy  Ada  Implementation  Guide  [^76] 

•  Experiences  in  Delivering  a  Large  Ada  Project  [50] 

•  TRWs  Ada  Process  Model  for  Incremental  Development  of  Large  Software  Systems  [1 95] 

•  The  Second  Ada  Project:  Reaping  the  Benefits  [152] 

•  What  Every  Good  Manager  Should  Know  About  Ada  [27] 

•  Advanced  Automation  Systems  Experiences  with  Ada  [101] 
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5.  Learning  Ada:  Training  Impiications 


5.1.  Rationale  for  Ada  Training 

Maximizing  the  benefits  of  Ada  requires  knowing  the  software  engineering  techniques  and 
disdpiines  that  Ada  supports  as  wait  as  the  ianguage.  it  is  more  expensive  to  teach  software 
engineering  and  Ada  than  to  teach  just  Ada.  and  it  is  necessary  to  teach  software  engineering 
in  conjunction  with  the  introduction  of  Ada.  Of  course,  Ada  training  wiii  vary  among  employees 
as  not  everyone  needs  the  same  level  of  expertise  in  Ada  and  software  engineering. 

An  effective  training  program  is  a  key  part  of  developing  an  organization’s  software  engineering  capability 
and  an  area  in  which  many  organizations  find  a  need  for  improvement  [147].  A  training  program  involves 
identifying  the  training  needs  of  the  organization,  the  projects,  and  the  individuals,  and  developing  and 
procuring  training  courses  to  address  these  needs  [183]. 

Appropriate  software  engineering  training,  supported  by  appropriate  levels  of  implementation  training 
(Ada,  other  languages,  tools,  etc.).  Is  required  to  realize  Ada's  positive  impact  on  schedule,  cost,  and 
quality  goals.  An  effective  training  program  should  be  based  on  the  following  points: 

•  Using  Ada  effectively  requires  more  than  just  knowing  the  language  —  It  requires  understanding 
the  software  engineering  techniques  that  the  language  supports  [21 7].  For  example,  data 
abstraction  and  information  hiding,  while  easy  to  understand  in  principle,  may  present  some 
difficulty  in  application  [140].  As  a  result,  quality  Ada  training  must  be  different  from  and  more 
extensive  than  training  for  other  languages.  While  Ada  training  will  cost  more  initially  because 
more  will  be  taught.  In  the  long  run,  the  use  of  Ada  and  its  associated  software  engineering 
concepts  can  reduce  individual  program  development  and  maintenance  costs. 

•  Training  is  necessary  for  both  acquisition  and  deveiopment/maintenance  personnel.  Software 
designers,  system  engineers,  Ada  programmers,  and  software  managers  in  both  industry  and 
government  all  need  to  know  about  Ada  and  its  assodated  software  engineering  techniques. 

Ada  training  should  address  all  these  groups,  but  the  depth  and  kind  of  knowledge  needed  will 
vary  for  each.  Because  of  Ada’s  new  concepts,  the  learning  curve  for  all  concerned  can  be 
steep. 

•  Management  training  is  especially  critical.  To  capably  manage  and  direct  programs  involving 
new  technology,  program  managers  must  understand  how  to  apply  the  technology 

[205, 23, 140]  and  how  it  differs  from  existing  approaches.  In  particular,  managers  should  under¬ 
stand  how  to  acquire  and  apply  metrics  in  software  development  [30, 197, 48].  Ada  projects  have 
different  profiles  from  projects  in  other  languages  and  managers  should  be  aware  of  this  in 
tracking  and  evaluating  metrics. 

•  Selecting  or  creating  the  training  program  for  all  levels  deserves  special  attention.  Many  trainers 
have  excellent,  well-integrated  courses  available;  many  teach  only  old  programming 
rnethodologies  and  concepts  wrapped  up  in  Ada  syntax.  Teaching  Ada  correctly,  from  cur- 
ricukjm  development  through  course  delivery  and  evaluation,  is  a  difficult  and  time-consuming 
task.  The  right  trainer  and  training  course  can  be  hard  to  find. 

•  It  is  useful  for  a  project  to  buikJ  a  core  group  of  knowledgeable,  well-trained  individuals  to  senre 
as  mentors  for  more  junior  personnel.  These  iixfividuals  must  be  very  knowledgeable  in  both  the 
application  of  Ada  and  software  engineering,  and  In  the  project  domain.  Experience  has  shown 
that  a  few  such  irxjividuals,  placed  in  key  positions  within  the  project,  can  have  a  stimulating 
effect  on  other  engineers. 
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In  the  absence  of  any  recognized  standard  for  evaluating  the  abilities  of  software  engineers, 
training  will  continue  to  be  the  responsibility  of  the  project  manager.  Managers  may  have  to 
select  personnel  using  project-specific  criteria  and  then  train  them  to  achieve  the  required  level 
of  software  development  expertise. 


5.2.  Audiences  and  Course  Content 

All  personnel  need  some  Gaining  in  Ada  and  its  associated  software  engineering  concepts  to 
obtain  the  maximum  benefits  from  using  Ada.  In  addition,  an  Ada  training  program  should 
always  consider  the  background  of  students  and  the  goals  of  fhe  project. 

There  are  several  target  audiences,  each  with  their  own  perspectives,  that  may  require  education  or 
training  [205, 192].  These  include: 

•  Management  personnel 

•  Executives:  focused  on  business  issues 

•  Software  managers:  focused  on  technical  issues  and  risks 

•  Non*software  managers:  focused  on  management  implications  of  Ada  use 

•  Technical  personnel 

•  Engineers:  including  systems  engineers  and  top-level  designers 

•  Programmers  and  analysts:  including  implementers  and  testers 

•  Project  support  personnel:  including  administrative,  configuration  management,  and 
software  quality  assurance  personnel 

•  Trainers 

Following  are  some  guidelines  regarding  target  audiences  and  key  content  material: 

•  Prior  programming  language:  The  background  of  students  attending  the  classes  must  be 
considered  in  course  design.  For  example,  software  engineers  who  have  not  used  languages 
with  dynamic  data  capabilities  (i.e.,  access  types)  will  probably  need  more  extensive  training 
than  those  with  prior  exposure  to  these  concepts.  Examples  of  languages  without  these 
capabilities  are  assembler  and  FORTRAN.  Such  individuals  can  be  easily  ovenvhelmed  in  train¬ 
ing  courses  that  are  too  intensive  and  too  short,  initial  training  for  these  individuals  can  take  3 
weeks;  becoming  truly  productive  using  Ada  can  take  4  to  6  months  of  experience.  Those  who 
already  know  a  structured  high-order  language  like  PASCAL  should  assimilate  the  new  tech¬ 
niques  more  rapidly.  However,  beware  of  teaching  by  analogy  (i.e.,  by  showing  a  construct  in  an 
old  language  and  then  demonstrating  how  to  accomplish  the  same  thing  in  the  same  way  in 
Ada).  This  leads  to  a  continuation  of  the  problems  of  earlier  software  development  generations 
written  in  new  syntax,  e.g.,  AdaBOL  or  AdaTRAN.  The  student  is  less  likely  to  readily  adopt  new 
ways  of  accomplishing  old  tasks  that  are  more  powerful  and  more  suited  to  Ada,  taking  advan¬ 
tage  of  ”new”  Ada  features  such  as  packages,  tasking,  exceptions,  aggregate  assignments,  use 
of  Boolean  expressions,  etc.  Students  must  be  taught  to  think  in  Ada  [202]. 

•  Prior  training:  The  knowledge  and  experience  of  students  should  be  considered;  prior  atten¬ 
dance  in  programming  courses,  software  engineering  courses,  or  software  acquisition  courses 
cannot  be  assumed  to  have  prepared  students  adequately  for  project  needs.  Certain  aspects  of 
software  issues  may  have  been  taught,  but  the  inclusion  of  appropriate  Ada  material  should  not 
be  assumed.  Indeed,  a  paradigm  shift  is  required  to  think  in  terms  of  libraries  and  reuse  as  first 
options. 

•  Software  engineering:  All  personnel  need  an  introduction  to  the  concepts  of  software 
engineering  [217].  System  and  software  engineers  and  software  testing  personnel  need  an  in- 
depth  exposure  to  the  concepts,  principles,  and  practices  of  software  engineering.  In  addition. 
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these  development  personnel  will  need  to  be  learn  techniques  for  implementing  these  software 
engineering  concepts  in  Ada. 

•  Ada  programming  language:  Although  the  management  and  technical  audiences  described 
above  need  Ada  training,  the  content  and  level  of  the  training  may  vary  significantly  with  the 
audience  [192].  Managers  need  an  overview  and  an  understanding  of  Ada  capabilities,  risks,  and 
impact  on  their  processes,  while  software  engineers,  systems  engineers,  and  software  test  per¬ 
sonnel  will  need  more  extensive  Ada  training. 

•  Software  design:  Engineers  concerned  with  software  design  will  need  training  in  the  use  of 
Ada-based  program  design  languages  (PDL).  In  addition,  there  are  several  new  methodologies 
that  take  advantage  of  the  concepts  in  Ada  as  part  of  the  design  process 

[21 1 , 58, 53, 54, 65, 55).  The  Challenge  for  any  training  program  is  to  provide  effective  training 
for  software  engineers  to  design  systems  that  are  elegant,  while  stressing  the  implications  of  the 
design  options  to  performance  concerns.  Designers  need  to  become  especially  cognizant  of  the 
long-term  maintenance  costs  of  their  design  efforts. 

•  Compilers  and  software  tools:  Software  engineers  developing  Ada  software  for  embedded 
systems  need  to  understand  how  the  Ada  compiler,  runtime  system,  and  tools  used  on  a  projea 
affect  memory  and  throughput  constraints.  In  particular,  in  embedded  systems  programming 
there  may  be  a  need  to  use  compiler  vendor-supplied  routines  to  integrate  with  the  operating 
system  or  runtime  environment.  These  needs  should  be  examined  for  an  Ada  solution  (see 
[151]  and  Section  8.4)  before  interfacing  to  another  language  to  obtain  this  mntime  support. 

•  System  engineers:  System  and  software  engineers  responsible  for  hardware  and  software 
integration  will  need  a  thorough  understanding  of  the  systems  engineering  impact  of  high-order 
language  selection.  Tradeoffs  to  be  considered  include;  whether  a  compiler  is  available  for  the 
chosen  processor.  Its  capabilities,  and  its  requirements  in  terms  of  space  and  speed. 

•  Software  testing:  Software  testing  personnel  need  to  understand  how  Ada  language  constnjcts 
such  as  packages,  generics,  and  tasks  affect  testir^  approaches  [216].  In  addition,  separate 
compilation  in  Ada  affords  earlier  testing  of  some  modules  through  drivers. 

•  Configuration  management:  Configuration  management  personnel  need  to  understand  how 
Ada  language  features  such  as  packages  and  program  libraries  affect  configuration  manage¬ 
ment  procedures.  They  may  also  require  special  training  on  tools  that  provide  configuration 
management  for  Ada  software  systems.  The  addition  of  libraries  for  reuse  purposes  may  also 
complicate  the  configuration  management  aspects  of  new  development  projects.  These  con¬ 
cepts  should  be  part  of  the  training  for  software  engineers  as  well. 

•  Management:  Managers  ^iiould  obtain  an  understanding  of  software  engineering  principles, 

Ada  concepts,  the  impact  of  methodologies  on  the  software  architecture,  the  impact  of  Ada  on 
the  software  and  system  life  cycle,  the  costs  and  c«q3abilities  of  tools,  and  hardware  and  software 
interaction.  Senior  managers  may  not  need  to  know  detailed  language  syntax,  but  they  may 
need  an  understanding  of  certain  language  concepts,  such  as  the  package  concept  (to  ap¬ 
preciate  Ada’s  defined  support  for  modularity),  or  exceptions  (Ada’s  mechanism  for  error  han¬ 
dling).  This  becomes  critically  important  if  design  reviews  or  inspections  are  done  using 
Ada/PDL  or  Ada  code.  Managers  should  be  taught  the  means  whereby  metrics  can  be  acquired 
and  used  in  the  development  of  a  software  project.  Understanding  these  concepts  may  improve 
the  overall  understanding  of  a  development  or  maintenance  effort.  In  addition,  the  total  quality 
concepts  (i.e.,  TQM  or  TQL)  must  be  understood  as  part  of  a  continuous  effort  to  improve  the 
end  product  through  software  process  improvement. 

•  Design  reviews:  Personnel  attending  design  reviews  should  have  some  understanding  of  how 
Ada  will  affect  the  software  architecture.  Design  cannot  always  be  language-indeperxlent  if  the 
language  affords  a  capability  worth  exploiting  in  the  design. 

•  Subcomraetors:  Training  requirements  should  be  consistently  applied  throughout  the  organiza¬ 
tion.  as  well  as  by  any  subcontractors.  This  will  help  ensure  continuity  In  methodology,  stan¬ 
dards,  and  approach  across  the  entire  development  effort  [140]. 
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5.3.  Evaluating  Training  Programs 

The  most  important  aspects  of  any  Ada  training  program  are  a  software  engineering  emphasis 
and  hands-on  practice.  The  quality  of  the  course  material  and  the  tjackground  and  experience 
of  the  instructor  are  also  important  considerations. 

Following  are  some  guidelines  for  evaluating  Ada  training  programs: 

•  Tailoring:  Training  can  be  purchased  or  developed  internally.  Curricula  developed  internally  or 
customized  for  an  organization  tend  to  be  more  effective  because  they: 

*  provide  for  curriculum  coordination 

•  can  embody  specific  methodologies  and  standards 

*  can  be  oriented  toward  specific  tools  and  hardware  considerations 

•  are  generally  more  responsive  to  sudden,  short-term  needs 

The  price  for  this  extra  effectiveness  is  continual  improvement  of  the  material  through  the  intro¬ 
duction  of  new  material  and  ideas.  Internal  trainers  will  need  to  be  assigned  full-time  respon¬ 
sibility  for  preparing  and  updating  this  training. 

Training  prepared  by  in-house  personnel  is  industry's  prefen’ed  way  for  Ada  training  and  was 
used  by  36  percent  (the  largest  percentage)  of  the  organizations  sunreyed  [32].  Extensive  use  of 
training  prepared  by  in-house  personnel  while  acquiring  an  organization's  first  Ada  compiler  or 
while  developing  an  organization's  Ada  capability  has  been  shown  to  be  significantly  related  to 
early  use  of  Ada  for  software  development  projects  [32]. 

•  Emphasis:  The  emphasis  of  courses  should  be  on  understanding  what  the  language  can  do 
and  how  it  should  be  used  to  produce  well-engineered  systems.  Courses  that  teach  only  the 
syntax  and  semantics  (the  grammar  and  meaning)  of  Ada  should  be  avoided.  Course  content 
should  emphasize  software  engineering  principles  with  Ada  examples  showing  how  to  implement 
them.  Care  should  be  taken  to  evaluate  the  training  program  to  insure  that  the  entire  life  cycle 
and  its  implications  are  considered. 

Training  courses  often  tend  to  focus  solely  on  the  coding  phase.  There  are  two  separate  schools 
of  thought  on  this  problem.  One  is  to  have  the  student  begin  writing  code  immediately  so  as  to 
provide  some  imniediate  gratification,  then  the  rest  of  the  life  cycle  will  become  meaningful.  The 
other  school  of  thought  stresses  that  students  need  to  know  the  implications  of  what  they  are 
doing  before  they  start  writing  code.  In  general,  the  second  school  of  thought  is  the  preferred 
approach. 

•  Length  and  topics:  For  any  introductory  course,  a  minimum  ot  five  class  days  is  required  to 
teach  the  basics  of  the  language  and  to  introduce  tfw  underiying  software  engineering  principles. 
These  class  days  should  be  spread  over  a  minimum  of  two  weeks  and  reinforced  with  hands-on 
design  and  programming  exercises.  Additional  classes,  which  include  Ada's  more  sophisticated 
features  and  implementation  tradeoffs,  will  be  required  for  people  who  will  use  Ada  heavily,  who 
do  not  have  previous  HOL  background,  or  who  will  be  responsible  for  design  activities. 

Refresher  courses  should  be  offered  periodically  after  the  initial  training. 

•  Equipment:  All  training  should  be  on  the  specific  compiler  and  tool  set  to  be  used  in  the 
development  effort.  The  user  interface  for  different  vendor  compilers  is  significantly  different, 
and  there  is  no  standardization  on  the  means  of  managing  libraries  or  invoking  tools.  Thus,  to 
avoid  retraining  costs  and  time,  it  is  advisable  to  conduct  the  training  on  the  actual  compiler  and 
tool  set  to  be  used.  Only  validated  compilers  should  be  used. 

•  Documentation:  In  addition  to  handouts  of  course  materials,  model  solutions  to  problems 
should  be  available;  they  are  an  especially  useful  way  to  teach  the  Ada  language  and  its  under¬ 
lying  principles.  The  contents  of  reuse  libraries  can  also  be  used  for  familiarizing  students  with 
the  tools  at  their  disposal. 
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•  Hand8K>n  lab:  It  is  imperative  that  hands-on  programming  exercises  be  a  major  component  of 
the  training  process.  Just  as  it  is  difficult  to  learn  how  to  tepair  radar  sets  or  jet  engines  without 
practical,  aji^lied  work,  the  same  is  true  for  building  computer  software  and  learning  computer 
languages.  In  fact,  the  more  detailed  the  training,  the  rrwre  imperative  hands-on  exercises  be¬ 
come.  For  exampie,  in  classes  dealing  with  using  Ada  for  a  specific  embedded  processor,  there 
is  no  substitute  for  writing  software  with  the  compiler  and  tool  set  that  will  be  used  on  the  actual 
development  program.  The  software  engineers  working  at  this  level  need  to  understand  the 
performance  and  limitations  of  a  particular  tool  set. 

•  Monitoring  progress:  The  training  program  should  have  methods  for  measurir^  student 
progress,  providing  student  feedback,  and  evaluating  course  effectiveness.^  Since  hands-on 
training  is  essential,  a  careful  and  complete  review  of  each  programming  project  should  be  made 
by  the  instructor.  This  will  include  de/a/7dd comments  on  the  design  approach,  the  selection  of 
Ada  features  used  to  accomplish  the  design,  and  the  use  of  new  Ada  concepts  where  ap¬ 
propriate. 

•  Instructor  availability:  A  trained  instructor  must  be  available  to  help  students  and  provide 
guidance  when  required.  The  instaictor  must  have  a  wide-ranging  experience  in  both  the  use  of 
Ada  and  in  design  problems  for  the  likely  domain.  Finally,  the  instmctor  must  be  well  versed  in 
the  concepts  of  software  engineering.  Practical  experience  in  the  development  of  software¬ 
intensive  systems  would  also  be  particularly  valuable  for  the  instructor. 

•  Computer*assl8ted  Instruction  (CAI)  and  video  tapes:  These  are  good  suppiementaltoo\s 
for  teaching  language  syntax  and  providing  overviews  and  review.  However,  they  should  not  be 
the  focus  of  the  training  effort  because  they  generally  do  not  have  a  software  engineering  em¬ 
phasis.  Even  when  they  do,  nothing  can  replace  the  effectiveness  of  good  classroom  instruction. 

•  Real  project  use:  To  achieve  maximum  training  effect,  personnel  should  be  assigned  im¬ 
mediately  to  an  Ada  project  where  experienced  Ada  software  engineer(s)  are  available  for  con¬ 
sultation  for  the  first  4  to  6  months.  If  the  student  does  not  apply  the  new  knowledge  soon  after 
instmction,  the  knowledge  rapidly  diminishes. 

In  addition,  some  organizations  have  improved  training  success  by  training  project  teams.  These 
teams  can  also  be  exposed  to  continuing  training  which  stresses  applying  Ada  within  the  context 
of  the  project's  processes  and  infrastoicture. 


5.4.  Selecting  Training  Programs 

An  Ada  ^ainirtg  program  shouid  be  pianned  and  seiected  based  on  an  understanding  of  the 
learning  needs  of  those  who  will  be  trained  and  the  requirements  of  their  projects. 

As  discussed  previously,  there  are  many  factors  to  consider  when  selecting  a  training  curriculum,  not  the 
least  of  which  is  the  material  to  be  covered,  the  depth  of  training,  who  shouid  be  trained,  and  the 
qualifications  of  the  instructor.  As  a  general  guide,  the  following  items  can  be  used  to  prepare  for  the 
selection  of  appropriate  training: 

•  A  thorough  curriculum  outline  for  each  different  learner  population  in  the  organization,  with  learn¬ 
ing  objectives,  content  outline,  instructional  strategy,  and  suggested  training  media  (at  least  two 
general  populations  can  be  anticipated:  management  and  engineering). 

•  A  vendor  selection  guide  that  identifies  how  to  select  vendor  training  materials  for  the  Ada  train¬ 
ing.  This  is  not  an  easy  task  and  could  take  several  weeks  to  create.  The  guide  must  be 


poGsible  approach  here  is  the  use  of  before  and  after  course  tasting. 
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predicated  on  a  thorough  needs  assessment  of  the  populations  and  the  curricula  tailored  accord¬ 
ingly.  This  is  a  time-consuming  and  labor-intensive  effort,  requiring  investigation  and  ^alysis  for 
each  learner  group.  All  persons  to  be  trained  will  need  software  engineering  concepts*  as  a 
significant  part  of  any  Ada  training. 

A  guide  with  two  parts  should  be  created  for  this  purpose.  The  first  part  should  discuss  general  issues 
relevant  to  vendor  selection  and  can  be  prepared  to  be  applicable  organization  wide.  The  second  part 
should  discuss  detailed  considerations  of  how  to  customize  the  first  part  to  tailor  it  for  a  specific  project  or 
group  within  the  organization. 

The  selection  materials  can  take  the  form  of  a  document  and  briefing  for  senior  management  in  the 
organization,  with  a  more  detailed  planning  document  developed  for  project  approval  and  use.  This 
planning  document  should  contain  a  statement  of  need,  appropriate  project  objectives,  a  suggested  ap¬ 
proach  to  the  task,  expected  benefits,  and  expected  product. 

Other  factors  that  an  organization  may  consider  in  selecting  a  vendor  include: 

•  Third  party  references;  observations  from  people  from  different  organizations  that  have  taken  the 
training. 

•  Evaluations  of  selected  individuals  who  atterxj  the  training  before  committing  an  organization  to 
its  use. 

•  Availability  of  "train  the  trainer"  training. 


5.5.  For  More  Information  . . . 

The  following  resource  recommendations  are  intended  as  an  Initial  starting  point  for  those  looking  for 
more  information  about  Ada  training.  Refer  to  Appendix  B  for  contact  information. 

•  Ada:  Helping  Executives  Understand  the  Issues  [220] 

•  The  Pedagogy  and  Pragmatics  of  Teaching  Ada  as  a  Software  Engineering  Toot  [1 74] 

•  Practical  Methods  for  Introducing  Software  Engineering  and  Ada  into  an  Actual  Project  [41  ] 

•  Holistic  Case  Study  Approach  to  Ada-Based  Software  Engineering  Training  [181] 

Ada  Information  Clearinghouse  (AdalC):  AdalC  has  information  about  upcoming  classes,  seminars, 
etc.  For  more  detailed  Information,  the  AdalC  publishes  the  CREASE:  Catalog  of  Resources  for  Educa¬ 
tion  in  Ada  and  Software  Engineering  [134]. 

Ada^OVIAL  Newsletter:  This  newsletter  is  published  at  Wright  Patterson  AFB,  Ohio.  Several  pages  in 
each  issue  are  allocated  to  training  and  other  product  announcements. 

Ada  Software  Engineering  Education  and  Training  Team  (ASEET):  This  group  examines  issues  in 
providing  quality  and  timely  Ada  education  and  training.  The  team  is  producing  a  database  of  information 
on  Ada  training  and  education  material  known  as  the  ASEET  Material  Library  (AML).  The  AML  consists 
of  course  syllabi,  lecture  notes,  overhead  transparencies,  books,  articles,  notes,  etc.,  that  can  be  obtained 
by  DoD  personnel  and  copied  at  cost  by  non-DoD  personnel.  All  courseware  is  non-copyrighted. 


^How  much  content  in  software  engineering  Mn'll  be  needed  can  be  expected  to  vary  with  the  diKerent  leamer  groups. 
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6.  Software  Production  Technology 

6.1.  Software  Development  Terms  and  Concepts 

The  following  terms  and  concepts  are  explained  in  this  section:  host/development  computer, 
target  conputer,  embedded  computer,  source  code,  object  code,  runtime  software,  program 
library,  compilers,  linking,  debugging,  downloading,  and  program  execution. 

This  section  introduces  generic  software  deveiopment  terms  and  concepts  discussed  in  the  rest  of  this 
handbook.  To  focus  on  areas  of  critical  importance  and  to  provide  a  basis  for  subsequent  discussions, 
this  section  concentrates  on  the  process  of  transforming  source  code  developed  by  a  software  engineer 
into  object  code  that  will  execute/run  on  a  target  computer.  The  process  of  code  transformation  is  a 
small,  but  vital,  part  of  the  overall  systems  development  life  cycle.  Readers  already  familiar  with  these 
items  can  skip  to  Section  6.2,  which  discusses  Ada  compilers. 

An  Ada  implementation  (or  an  Ada  compilation  system)  is  an  Ada  compiler,  linker,  library  manager,  run¬ 
time  software,  and  any  other  necessary  software  associated  with  its  host  computer  and  the  target  com¬ 
puter.  These  two  computers  are  used  in  the  process  of  software  development: 

•  Host  (or  development)  computer:  The  software  development  process  typically  takes  place  on 
the  host  or  development  comjxjter.  This  computer,  whether  it  be  a  large  mainframe  computer  or 
a  personal  workstation  or  a  personal  computer,  serves  as  the  host  lor  the  development  software. 

•  Target  computer  (or  target  processor):  The  computer  that  mns  the  developed  software;  em¬ 
bedded  systems  examples  are  various  RISC  processors,  MIL-STD-1750A,  Intel  80x86  family, 
and  ^e  Motorola  68000  family. 

While  the  host  and  target  computers  can  be  the  same,  the  host  computer  is  often  different  from  the  target 
computer  because: 

•  More  (and  different)  resources  may  be  needed  to  design,  develop,  document,  compile,  and 
maintain  software  than  to  execute  it.  Such  resources  might  include  system  memory  and 
peripherals  such  as  disk  drives. 

•  In  many  systems,  such  as  weapons  systems  or  other  real-time  systems  (air  traffic  control),  the 
target  oornputer  is  embedded  in  and  functions  as  an  integral  part  of  the  system.  Embedded 
computers  are  typically  small,  special-purpose  machines  dedicated  to  specific  operations  or 
furx:tions  and  therefore  not  suitable  for  developing  software.  Examples  of  embedded  computers 
are  processors  fouixl  in  automobiles,  household  appliances,  industrial  robots,  navigation  sys¬ 
tems,  and  process  control  equipment. 

When  the  target  computer  is  different  from  the  host  computer,  the  executable  code  must  be  transferred 
(downloaded!  to  the  target  computer  before  it  can  be  njn. 

As  Figure  6-1  shows,  the  software  developer  uses  an  interactive  software  tool  called  an  editor  to  create 
and  save  (and  later  modify)  the  source  code  for  each  of  the  many  units  (or  modules)  that  will  constitute 
the  completed  system.  The  source  code  is,  for  the  purposes  of  this  handbook,  written  in  a  high-order 
language  (HOL),  a  programming  language  such  as  Ada,  COBOL,  JOVIAL,  or  FORTRAN.  HOLs  enable  a 
software  engineer  to  write  in  an  English-like,  readable  form  rather  than  in  a  binary  machine  language 
unique  to  each  type  of  computer  system.  Not  shown  in  this  figure  are  various  front-erxl  CASE  tools  that 
aid  in  designing  the  system. 
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After  each  unit  is  created,  a  compiler  chocks  the  source  code  for  first-level  correctness  by  ensuring  that 
the  syntax  (grammar)  of  the  code  is  correct.  If  errors  a'?  identified,  the  process  cannot  continue,  and  the 
developer  then  uses  the  editor  to  correct  the  error(s)  and  resubmits  the  module  to  the  compiler.  If  no 
errors  are  found,  the  compiler; 

•  translates  the  source  code  into  object  modules  *he\  will  (eventually)  run  on  the  target  computer 
(in  applications  where  often  the  host  and  target  computers  are  different,  a  compiler  that  trans¬ 
lates  source  code  into  a  machine  language  for  other  than  the  host  computer  is  known  as  a  cross 
compiler), 

•  produces  various  output  listings  (see  Section  6.2.2.3),  and 

•  produces  symbol  tables  that  are  used  in  conjunction  with  debuggers. 

Relationships  among  object  modules  (and  in  some  cases,  the  object  modules  themselves)  are  maintained 
in  a  program  library,  libraries  vary  in  their  sophistication,  depending  on  the  requirements  and  capabilities 
of  the  high-order  language  being  used.  Ada  libraries  are  much  more  sophisticated  than  libraries  for  other 
languages. 

The  independently  compiled  object  modules  must  be  //nked  together  before  the  program  can  be  ex¬ 
ecuted.  When  the  application  code  is  linked,  the  appropriate  runtime  software  is  automatically  included. 
Runtime  software  provides  the  additional  supporting  functions  required  for  executing  programs  cn  a 
specified  target  computer.  Each  target  computer  and  each  computer  language  requires  its  own  specific 
runtime  support  library.  For  Ada,  functions  most  likely  harKfled  by  runtime  software  include  scheduling, 
parameter  passing,  storage  allocation,  and  some  kinds  of  error  handling.  As  part  of  the  linking  process, 
additional  consistency  checks  are  performed;  in  particular,  any  missing  or  possibly  obsolete  compilation 
units  are  reported.  The  outputs  of  the  linking  step  include; 

•  an  executable  (ready  to  run)  module 

•  printed  listings,  generally  called  a  link  map,  that  describe  the  structure  of  the  executable  module 

The  executable  module  can  be  executed  and  tested  on  either  the  host  or  the  target  machine.  Usually,  the 
host  machine  will  continue  to  be  used,  especially  during  the  early  phases  of  software  debugging  and 
testing,  because  of  the  greater  resources  available  on  the  host.  If  the  host  machine  is  not  the  target 
computer,  it  is  possible  to  simulate  execution  of  the  developed  software  by  using  a  simulator/debugger. 
The  simulator/debugger,  which  is  also  referred  to  as  a  target  simulator,  mns  on  the  host  machine  and 
mimics  the  timing  and  functional  behavior  of  the  target  machine,  thereby  providing  a  good  view  of  execu¬ 
tion  in  the  target  domain.  An  additional  level  of  problems  can  then  be  discovered  before  the  software  is 
downloaded  to  the  target.  If  logic  errors  (errors  in  functionality  and  operation)  are  discovered,  the 
software  developer  must  return  to  the  editor  to  begin  the  correction  process. 

After  a  certain  confidence  level  is  reached  using  the  host-based  simulator/debugger,  the  ultimate  test  is  to 
download  the  executable  software  to  the  target  computer  and  execute  it  there.  While  simulators  or 
emulators  are  Intended  to  mimic  the  timing  and  functional  behavior  of  the  target  machine,  they  may  have 
some  differences  in  performance  or  execution  that  may  mask  problems.  There  is  no  substitute  for  hot 
testing  software  (i.e.,  testing  on  the  target  processor).  On  the  target  processor,  debugging  tools  are  very 
helpful  for  locating  errors.  Errors  discovered  during  software  execution  are  the  most  expensive  to 
resolve. 
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6.2.  Ada  Compilers 

Initial  Ada  compilers  primarily  focused  on  adhering  to  the  language  standard  and/or  establish¬ 
ing  a  market  presence.  Subsequent  generation,  production-quality  compilers  are  available  for 
many  more  processors,  and  are  focused  on  optimized  object  code.  Some  important  issues  to 
consider  when  selecting  an  Ada  compiler  are  compiler  validation  and  compiler  evaluation. 

While  all  tools  used  in  the  software  development  process  are  important,  the  Ada  compiler  continues  to 
attract  the  most  attention,  in  part  because  of: 

•  the  requirement  for  compiler  validation  to  ensure  that  a  compiler  conforms  to  the  language  stan¬ 
dard;  and 

•  the  need  for  compiler  evaluation,  which  should  be  used  to  determine  the  usability  of  a  validated 
compiler  for  a  particular  application's  needs. 

These  issues  are  briefly  addressed  below.  The  Ada  Adoption  Handbook:  Conrpiler  Evaluation  and  Selec¬ 
tion  [226]  addresses  these  issues  in  greater  depth. 

6.2.1.  Compiler  Validation 

To  ensure  that  program-dependent  dialects  of  Ada  do  not  arise,  the  DoD  requires  that 
validated  Ada  compilers  be  used  for  creating  software  to  be  delivered  to  or  maintained  by  the 
government.  However,  not  all  validated  compilers  may  be  suitable  for  every  program.  Each 
program  must  select  an  appropriate  compiler  and  tool  set,  and  make  allowable  improvements 
when  necessary.  Compiler  modifications  are  acceptable  If  they  do  not  change  the  language. 
Modified  compilers  must  be  revalidated,  but  at  the  discretion  of  the  program  manager. 

While  Ada  has  been  mandated  as  a  standard  by  the  Department  of  Defense,  it  is  not  enough  just  to  have 
a  standard  —  the  standard  nrarst  be  enforced.  The  purpose  of  validation  is  to  require  conformity  of  Ada 
Implementations  with  the  language  standard.  Currently,  validation  measures  oonfomiity  with  the  current 
language  standard  [13];  after  the  adoption  of  the  Ada  9X  standard,  the  validation  process  will  measure 
conformity  with  the  Ada  9X  standard.  The  official  AJPO  list  (October  1992)  contains  270  validated  base 
Ada  compilers  and  231  denVed  compilers,^  which  are  available  for  a  wide  variety  of  host-target  combina¬ 
tions.  In  general,  only  validated  Ada  compilers  can  be  used  for  DoD  applications. 


“  Onoe  an  Ada  compiler  has  a  current  validation  certificate  (the  base  compiler),  then  variations  or  modifications  to  that  compiler 
and/or  its  configuration  result  in  a  derived  compiler.  A  derived  compHer  must  conform  to  the  Ada  programming  language  in  every 
respect  and  by  the  same  measure  as  does  the  base  compiler  from  which  it  was  derived.  To  be  considered  a  derived  compiler,  artd 
therefore  acquire  status  as  an  Ada  validated  compiler,  derived  compilers  must  be  registered  by  vendors  with  the  AJPO.  Example: 
Consider  a  validated  compiler  hosted  and  targeted  to  a  VAX  750.  The  vendor  could  then  irxficate  that  the  same  compiler  running  on 
VAX  780, 785, 8600, 8800  and  other  members  of  the  VAX  family  is  derived  because  it  meets  the  tour  criteria  tor  derived  validations: 

1 .  the  validation  certificate  fc  r  the  base  implementation  has  an  expiration  date  at  least  three  months  beyond  the  time  of 
derivation; 

2.  the  host  and  target  computer  systems  of  both  the  base  and  derived  Ada  implementations  have  compatible  instruction 
sets  and  operating  systems; 

3.  the  derived  Ada  implementation  contains  an  Ada  compiler  that  was  obtained  (dsrrvsd)  from  the  Ada  compiler  of  the 
base  implementation; 

4.  the  ACVC  result  for  the  Ada  implementation  is  either  the  same  as  or  has  minor  justifiable  differences  from  the  base 
implementation. 

For  more  details,  refer  to  the  Ada  Compiler  Validation  Procedures  (3). 
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The  validation  process  is  carried  out  by  the  Ada  certification  body  consisting  of  the  Ada  Joint  Program 
Office  (AJPO)  for  overall  direction,  the  Ada  Validation  Organization  (AVO)  and  the  Ada  Compiler  Valida¬ 
tion  Capability  (ACVC)  Maintenance  Organization  (AMO)  for  technical  support,  and  the  Ada  Validation 
Facilities  (AVF)  for  performing  validations. 

There  are  two  ways  of  obtaining  validated  status;  by  AVF  testing:  and  for  "derived"  compilers  only,  by 
registration.  With  Ada,  validation  by  testing  is  achieved  by  testing  for  compliance  with  the  ACVC,  an 
integrated  set  of  tests,  procedures,  software  tools,  and  documentation  used  to  validate  Ada  compilers. 

After  a  compiler  has  been  validated  by  on-site  testing  at  an  Ada  Validation  Facility  (AVF),  the  AVF 
issues  a  Validation  Summary  Report  (VSR),  which  reports  the  results  of  the  compiler's  validation 
testing.^  Expiration  dates  for  these  validation  certificates  is  twelve  months  after  the  expiration  of  the 
ACVC  version  used  to  obtain  the  certificate. 

Since  first  introduced  in  1983,  the  ACVC  has  been  extended  and  revised  to  increase  both  the  depth  and 
breadth  of  the  test  coverage.  The  first  version  of  the  ACVC  had  approximately  1700  tests;  the  current 
version  VI  .1 1  has  3719  tests.  If  a  compiler  passes  all  the  applicable  ACVC  tests,  it  is  said  to  be 
validated.  Depending  on  the  characteristics  of  the  target  computer,  some  tests  may  not  be  applicable. 
Current  policy  regarding  Ada  validation  is  tending  toward  a  more  stable  test  suite  based  on  expected 
usage.  After  removing  tests  of  little  value  and  adding  tests  for  Ada  9X,  the  suite  will  stabilize  at  about 
4000  tests. 

Although  ensuring  that  Ada  implementations  conform  to  the  standard  has  a  long-term  benefit,  the  value  of 
validation  to  an  individual  program  is  limited.  Validation  should  be  regarded  as  a  necessary,  but  not 
sufficient,  condition.  The  program  manager  should  know  that: 

•  Validation  does  not  mean  a  compiler  is  free  of  errors  —  no  tests  can  detect  a// errors  in  a  com¬ 
plex  software  product. 

•  Revalidation  is  required  periodically.  The  general  rule  is  that  a  compiler  must  be  revalidated 
under  each  new  release  of  the  ACVC  to  retain  its  validation  certificate,  but  the  rules  for  project 
compilers  incorporated  into  a  project  baseline  allow  this  compiler  to  be  used  throughout  the  life 
cycle  of  the  project. 

•  The  validation  process  is  nor  concerned  with  performance  or  usability  issues  such  as  compile¬ 
time  and  object-code  efficiency  (see  Section  6.2.2).  Validation  implies  only  a  minimal  level  of 
usability,  a  level  that  may  not  meet  the  needs  of  a  particular  program  or  application.  Con- 
sequentKy,  each  program  must  determine  whether  a  validated  compiler  meets  (or  can  be 
modified  to  meet)  its  needs. 

It  is  not  always  possible  to  havo  the  final  delivered  system  compiled  with  a  validated  (under  the  current 
validation  suite)  Ada  compiler.  Validation  policies  [3]  include  the  concept  of  a  baselined  project 
compiler —  a  particular  Ada  implementation  selected  for  use  for  the  life  of  a  particular  project.  It  may  be 
necessary  to  ensure  proper  and  systematic  implementation  baselining  of  the  software  development  en¬ 
vironment,  because  that  compiler  and  environment  will  be  used  upon  system  delivery  to  maintain  that 
system. 


®^The  ACVC  test  suite  is  available  through  the  National  Technical  Infonnation  Service  (NTIS)  Federal  Computer  Products  Center. 
U.S.  Department  of  Commerce,  Springfield.  VA  22161. 

“Copies  of  these  Validation  Summary  Reports  can  bo  obtained  from  either  the  NTIS  or  the  Defense  Technical  Information 
Service  (DTIC),  Cameron  Station,  Alexandria.  VA  22304-6145. 
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The  requirement  to  use  only  validated  compilers  may  appear  to  pose  a  risk  when  combined  with  the  DoD 
requirement  to  revalidate  compilers  periodically.  After  all,  if  a  program's  conpiler  fails  revalkJation,  it  must 
be  corrected,  and  the  application  code  must  be  recompiled  and  completely  retested,  which  can  have  cost 
and  schedule  implications.  The  validation  procedures  and  guidelines  document  addresses  these  con¬ 
cerns  by  providing  the  following  guidance: 

•  Any  compiler  placed  under  baseline  project  control  must  be  a  validated  compiler.  Once  placed  in 
the  baseline,  the  compiler  does  not  have  to  be  revalidated  until  the  program  manager  finds  it 
prudent  to  confirm  that  the  compiler  still  conforms  to  the  standard. 

•  Program  managers  are  encouraged  to  use  the  validation  tests  to  ensure  that  compiler  main¬ 
tenance  changes  and  modifications  have  not  affected  the  ability  of  the  compiler  to  pass  the  tests. 

•  Retesting  is  recommended  at  major  program  baseline  milestones. 

In  short,  revalidation  testing  is  completely  under  the  control  of  the  program  manager  and  can  be 
scheduled  at  times  when  it  is  least  disruptive  to  the  program.  The  intent  of  the  AJPO  guidelines  is  to 
ensure  that  compilers  continue  to  conform  to  the  standard  without  imposing  an  undue  burden  on  program 
managers. 

Validation  ensures  conformance  with  the  ACVC  test  suite,  but  is  no  substitute  for  evaluation.  Evaluation 
ensures  compatibility  between  the  capabilities  of  an  Ada  implementation  and  the  project’s  needs. 

6.2.2.  Compiler  Evaluation 

A  number  of  factors  are  indicative  of  compiier  quality  and  usability.  A  project  should  select  a 
compiler  after  a  thorough  evaluation  based  on  its  specific  needs,  in  some  cases,  compiler 
improvements  and/or  customization  may  be  needed  tor  certain  programs. 

The  validation  process  is  no/ concerned  with  performance  or  usability  issues  such  as  compile-time  and 
object-code  efficiency.  As  validation  only  measures  conformance  to  the  language  standard,  compiler 
evaluation  efforts  should  determine  the  usability  of  a  validated  compiler  for  a  particular  application’s 
needs.  Each  program  must  determine  whether  a  validated  compiler  meets  (or  can  be  modified  to  meet) 

Its  needs. 

The  production  quality  of  an  Ada  compiler  is  usually  measured  minimally  in  terms  of: 

•  Complle>time  efficiency:  Speed  at  which  the  compiler  transforms  various  language  features 
and  compiler  capacity  in  terms  of  the  size  of  components  that  can  be  processed  and  generated. 

•  Object  code  efficiency:  Size  and  speed  of  the  resulting  object  code,  including  runtime  software. 
These  factors  are  often  compared  against  assembly  language  for  the  same  algorithm. 

•  Compiler  services:  Quality  of  error  messages,  types  of  error  recovery,  output  listings,  and  diag¬ 
nostic  information. 

•  Support  for  embedded  system  requirements:  Ability  to  precisely  control  and  interface  with 
hardware  system  functions. 

The  following  sections  address  these  issues.  Other  factors  that  should  be  considered  include  the  number 
of  known  bugs  or  limitations  in  the  compiler  (if  any),  stability  of  vendors  and  their  products,  documen¬ 
tation,  and  vendor  support. 
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Each  program  should  consider  these  factors  in  evaluating  the  quality  and  maturity  of  compilers  based  on 
their  criteria.  The  Ada  Compiler  Evaluation  Capability  (ACEC)  [100, 153, 154, 155]  provides  criteria  and 
tests  for  evaluating  Ada  compilers.^  Another  method  of  compiler  evaluation  that  has  been  used  is  em¬ 
bodied  in  the  Ada  Evaluation  System  (AES),  which  was  developed  in  the  United  Kingdom  [162].^*^  Also  in 
use  are  the  PIWG  benchmarks  [187],  used  to  test  performance  characteristics  of  the  software,  and  the 
Hartstone  benchmarks  [93, 92],  which  test  a  system's  ability  to  handle  hard  real-time  applications. 

6.2.2.I.  Complle-Time  Efficiency 

Ada  compilers  require  more  host  computer  resources  than  compilers  for  most  other  lan¬ 
guages,  in  part  because  the  compilers  are  required  to  check  for  more  kinds  of  programming 
errors. 

Ada  compilation  costs  can  be  significantly  reduced  if  a  compiler  has  special  support  tools  for 
managing  separately  compiled  units  efficiently.  These  costs  can  also  be  reduced  by  careful 
use  of  information  hiding  and  abstraction  in  Vie  design  of  the  software. 

Ada  is  intended  to  be  used  not  Just  for  small,  embedded  systems,  but  also  for  large  systems  ~  systems 
that  contain  hundreds  of  thousands,  even  millions,  of  lines  of  code.  The  software  in  such  systems  may  be 
compiled  hundreds  of  times.  Some  compilers  are  not  adequate  for  this  level  of  use,  due  to  speed  or 
capacKy  limitations. 

There  are  several  reasons  why  Ada  compilers  use  more  computing  resources  than  compilers  for  other 
programming  languages: 

•  Language  capability:  Ada’s  inherent  power  and  complexity  generally  mean  additional  process¬ 
ing  Is  required  by  the  compiler. 

•  Earlier  error  detection:  Ada  compilers  can  detect  certain  kinds  of  programming  errors  earlier 
than  they  would  normally  be  detected  in  other  languages.  A  type  of  error  Ada  will  catch  early  is 
the  classic  “apples  and  oranges"  problem.  For  exanple,  while  other  languages  might  allow 
numbers  representing  velocity  and  volume  to  be  added  together,  with  the  error  eventually  found 
during  integration  testing,  Ada  can  catch  such  errors  during  compilation.  Although  checking  for 
such  errors  has  a  price,  a  well-proven  software  engineering  principle  is  that  the  earlier  an  error  is 
detected,  the  cheaper  it  is  to  fix.  (Of  course,  some  errors  will  not  be  detected  by  a  compiler  for 
any  language;  these  must  still  be  caught  during  unit  or  integration  testing.) 

•  Library  management:  If  a  compiler  is  not  designed  properly,  some  required  error  checks  can 
consume  significant  resources.  The  key  issue  here  is  how  the  compiler  accesses  and  updates 
an  auxiliary  file  called  the  library.  Some  Ada  compilers  can  minimize  the  costs  of  accessing  and 
maintaining  the  library,  and  these  implementations  are  particularly  effective  in  their  support  for 
programming  large  systems.  For  example: 


*The  first  releaw  of  the  ACEC  occurred  in  August  1988.  The  current  ACEC  (Version  V3)  was  released  in  August  1992.  The 
ACEC  is  being  maintained  by  the  Language  Control  Facility  (see  Section  B.3)  and  is  distributed  by  the  Data  &  Analysis  Center  for 
Software  (DACS),  P.O.  Box  120,  Utica.  NY  13503,  Tel.  (315)  734-3696. 

^AES  is  not  cun'ently  being  distributed,  as  these  two  methods  are  in  the  process  of  being  merged. 


CMU/SEI-92-TR-29 


57 


•  Checking  for  inconsistencies  between  separately  compiled  units^^  can  contribute  to 
compile-time  inefficiency  if  the  compiler  does  not  efficiently  process  interface  infor¬ 
mation  declared  in  separately  compiled  packages. 

*  When  an  interface  package  is  changed,  some  compilers  cannot  assess  the  impact  of 
the  changes.  As  a  result,  large  portions  of  the  system  must  be  recompiled  unneces¬ 
sarily  to  ensure  no  inconsistencies  have  been  introduced. 

•  Optimization:  Optimization  refers  to  the  process  of  making  the  generated  object  code  more 
efficient  for  execution  while  insuring  that  the  functionality  of  the  code  remains  unchanged.  Op¬ 
timization  techniques  include  removing  redundant  code,  eliminating  unnecessary  runtime  error 
checking,  and  consolidating  memory  usage.  Since  optimization  of  object  code  is  especially 
important  in  embedded  systems,  some,  but  not  all,  Ada  compilers  devote  considerable  attention 
to  generating  high-quality  code.  This  is  perhaps  the  area  of  greatest  progress  since  the  first 
edftion  of  this  handbook  [109].  Such  optimization  requires  extensive  machine  analysis  of  the 
developed  software,  which  may  consume  considerable  resources.  The  use  of  host  resources  to 
produce  code  with  increased  target  performance  is  an  excellent  tradeoff,  after  the  software  being 
optimized  is  logically  correct.  Many  compiler  products  provide  different  levels  of  optimization  so 
software  development  personnel  can  choose  the  most  effective  level  of  optimization  for  a  par¬ 
ticular  stage  of  development. 

6.22.2.  Object  Code  Efficiency 

Experts  disagree  about  the  time  and  space  penalties  Incurred  tor  code  generated  by  compilers 
relative  to  optimal  hand  coding  In  assembly  language.  It  Is  clear,  however,  that  rapid  progress 
Is  being  made  In  optimized  code  generation  and  that  compilers  are  already  able  to  generate 
better  code  toan  the  "average"  assembly  language  coder  [151].  Furthermore,  production- 
quality  Ada  compiler  have  the  potential  to  generate  code  that  Is  more  efficient  than  code 
generated  tor  other  languages. 

Efficient  object  code  can  be  generated  by  Ada  compilers,  although  some  current  compilers  may  not  yet 
achieve  this  goal.  Just  because  some  compilers  may  generate  inefficient  code  does  not  imply  that  Ada 
code  must  be  inefficient;  more  highly  optimized  compilers  generate  code  that  is  as  efficient  as  code 
generated  for  other  hlgh-order  languages.  Good  optimizers  are  more  the  mle  now  than  in  the  past.  In 
fact,  some  Ada  features  potentially  allow  Ada  compilers  to  surpass  the  object-code  efficiencies  of  other 
languages.  For  example: 

•  More  efficient  machine  operations  can  be  used  to  manipulate  Ada’s  composite  data  structures. 

•  Certain  subprogram  calls  can  be  eliminated  by  putting  the  subprogram  code  “inline"  in  place  of 
the  call,  thus  saving  time. 

•  Compact  representations  for  data  can  be  specified  when  compared  to  the  compiler’s  normal  data 
layout  strategy,  saving  space. 

•  Certain  unnecessary  data  compatibility  checks  ordinarily  performed  at  runtime  can  be  omitted, 
saving  both  time  and  space. 

These  features  should  be  considered  by  those  programs  with  severe  object-code  effiderx^y  requirements. 
However,  other  language  features,  such  as  data  compatibility  checks  and  exceptions,  can  also  decrease 
object  code  efficiendes.  And  the  nintime  system  for  any  language  can  be  a  source  of  inefficiency  as  well. 
Some  items  of  concern  are: 


part  of  its  error  checking,  me  compiler  will  ensure  that  a  separately  compiled  Ada  subprogram  cannot  be  called  with  the 
wrong  number  of  parameters.  Using  separately  compiled  units  also  means  portions  of  the  system  can  be  chartged  without  having  to 
recompile  the  entire  system. 
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•  Loading  runtime  software:  With  some  compilers,  the  entire  runtime  software  is  loaded,  whether 
it  is  needed  or  not,  making  the  executable  code  unnecessarily  large.  Thus,  the  ability  to  include 
only  those  functions  that  an  application  needs  would  save  space.  This  capability  should  not 
cause  any  validation  concerns,  but  may  require  some  addittonal  intelligence  in  the  compiler  and 
the  linker.  Many  compilers  already  have  intelligent  linking,  eliminating  this  problem. 

•  Runtime  customization:  Significant  efficiencies  can  be  gained  if  portions  of  the  mntime  system 
are  tuned  to  a  particular  application. 

Where  severe  time  and  space  limitations  exist,  K  is  often  necessary  to  invest  in  program-specific  custom 
optimizations.  With  properly  designed  compilers,  the  process  of  creating,  testing,  and  documenting  such 
optimizations  can  be  relatively  inexpensive  when  compared  to  creating  a  totally  new  compiler.  But,  this 
process  is  usually  not  cheap  arxf  should  only  be  undertaken  when  a  serious  need  for  such  optimizations 
and  sufficient  resources  to  fund  such  efforts  exists. 

6.2J2.2.  Compiler  Services 

The  usability  of  a  compiler  is  affected  by  the  services  it  provides  beyond  the  generation  of  code. 

Compilers  differ  in  the  extent  to  which  they  provide  helpful  services  to  software  engineers.  The  compiler 
services  indicated  below  have  been  helpful  in  many  efforts  [121].  For  more  information,  see  [226, 179). 

•  Formatted  source  code  listing:  An  indented  listing  revealing  the  structure  and  control  flow  of 
the  source  code.  This  capability  is  sometimes  referred  to  as  a  pretty  printer,  these  tools  can 
often  be  tailored  to  allow  each  software  development  eftort  to  establish  its  own  formatting 

conventions.^^ 

•  Assembly  code  listing:  A  listing  showing  the  absolute  memory  location  of  each  machine  in¬ 
struction  in  the  target  computer. 

•  Interleaved  assembly  code  listing:  A  listing  showing  the  machine  code  generated  for  each 
Ada  statement.  (It  is  not  always  possible  to  produce  such  a  listing  for  highly  optimizing  com¬ 
pilers.) 

•  Set/use  listing:  A  listing  showing  where  variables  are  modified  and/or  read. 

•  Compiler  error  messages:  Explanations  of  programming  errors  found  by  the  compiler.  These 
messages  are  provided  at  the  point  of  the  error,  in  a  consolidated  listing,  or  both. 

In  addition,  the  following  services  are  specifically  Ada  oriented: 

•  Compilation  order  tool:  A  capability  that,  when  given  a  set  of  Ada  units,  determines  the  com¬ 
pilation  order. 

•  Automatic  recompilation  option:  An  option  whereby  the  compiler  finds  and  automatically 
recompiles  all  modules  requiring  recompilation. 

•  Recompilation  analyzer:  A  capability  (in  some  cases,  a  separate  tool)  that  analyzes  the  struc¬ 
ture  of  software  and  indicates  how  much  recompilation  will  be  caused  by  various  changes. 


**The  guidelines  contained  in  (138)  are  a  starting  point  (or  ouch  conventions.  Although  this  is  the  AJPO's  recommended  style 
guide,  it  can  be  tailored  to  allow  establishment  of  project  formatting  conventions. 
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6.2^.4.  Support  for  Embedded  System  Requirements 

Ada  corryjilers  are  now  being  built  to  address  the  special  needs  of  embedded  systems. 

Ada  was  intended  for  DoD  embedded  system  applications,  some  of  which  impose  special  requirements 
on  compilers.  For  example,  embedded  systems  typically  need  to: 

•  process  hardware  interrupts 

•  place  data  in  particular  memory  locations  (e.g.,  to  support  memory-mapped  I/O) 

•  specify  storage-efficient  representations  of  data 

•  implement  code  in  read-only  memory  (ROM) 

•  access  specialized  low-level  machine  instructions,  e.g.,  those  that  compute  trigonometric  func¬ 
tions  or  that  allow  merrwry  checks  (referred  to  as  a  built-in  test  —  BIT)  to  be  run  when  a  system 
would  othenwise  be  idle 

•  accomplish  required  actions  at  precisely  specified  times 

Early  Ada  implementations  did  not,  in  general,  address  these  specialized  needs  because  of  the  pressures 
and  demands  of  achieving  validation.  However,  validated  compilers  that  meet  the  special  needs  of  em¬ 
bedded  and  mission-critical  systems  are  now  available  from  many  vendors. 

6.2.3.  Compilers:  Action  Plan 

Several  factors  should  be  considered  in  evaluating  the  quality  and  maturity  of  compilers. 

Guidance  regarding  compiier  and  tool  evaluation  is  available  from  a  number  of  sources,  including  the 
Evaluation  and  Validation  Reference  System  [56, 57],  and  the  Ada  Adoption  Handbook:  Compiler 
Evaluation  and  Selection  [226].  Other  sources  indude  [233, 179]. 

The  following  suggestions  provide  general  guidance  for  compiler  acquisition: 

•  Host  machine  resources:  Plan  to  support  larger  host  machine  resources  (more  memory  and 
computing  power)  than  for  other  languages. 

•  Compiler  evaluation: 

•  Specify  additional  criteria  and  tests  a  validated  compiler  must  satisfy  to  meet  program- 
specific  needs. 

•  Develop  coding  guidelines  based  on  evaluation  results.  (Such  guidelines  should  con¬ 
form  with  the  recommendations  of  [138].) 

•  Compiler  services:  Ensure  that  needed  user  support  services  are  provided  by  the  compiler. 

•  Recompilation  costs:  Assess  vendor  support  for  reducing  the  costs  of  compiling  (and  recom¬ 
piling)  large  software  systems. 

•  Revalidation:  Balance  the  costs  of  revalidation  (including  recompiling  and  retesting  all  mission 
software)  with  the  advantages  a  new  compiler  version  may  have  in  terms  of  reiiability  (fewer 
bugs)  and  improved  object-code  quality,  as  well  as  life-cycle  support  for  the  new  compiler  ver¬ 
sion. 
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6.3.  Programming  Support  Environments 

6.3.1.  Overall  Status 

As  software  support  environments  will  never  reach  their  full  potential  for  any  programming 
language,  program  managers  should  concentrate  on  tool  functionality  and  compatibility. 

The  function  of  a  software  engineering  environment  (SEE)  is  to  support  the  development  and  main¬ 
tenance  of  large-scale  software  systems.  The  SEE  should  provide  support  across  the  devetopment  and 
maintenance  cycle  to  include  specification  development,  test  generation  and  testing,  program  manage¬ 
ment,  coding,  debugging,  and  configuration  management.  The  goals  of  a  SEE  complement  the  goals  of 
Ada,  and  include: 

•  common  tools  and  interfaces, 

•  tool  integration,  and 

•  software  transportability. 

Program  managers  should  primarily  concentrate  on: 

•  tool  functionality 

•  operational  compatibility  between  tools  (including  interfaces) 

The  following  sections  provide  action  plans  for  both  required  and  optional  devetopment  tools. 

6.3.2.  Required  Tools:  Action  Plan 

A  minimal  tool  set  is  needed  for  use  with  a  conpiler. 

As  a  first  objective,  a  program  manager  should  ensure  that  a  good  basic  tool  set  is  used.  In  addition  to  a 
compiler,  the  minimally  required  tools  include: 

•  Editor:  An  interactive  tool  for  creating  documentation  and  source  code. 

•  Debugger:  Symbolic  debuggers^  for  Ada  are  fast  becoming  essential  devetopment  and  produc¬ 
tivity  tools.  The  debugger  and  compiler  work  as  a  complementary  pair,  where  both  tools  share 
common  data  structures  known  as  symbol  tables  (see  Figure  6-1)  and  are  therefore  best  pur¬ 
chased  from  the  same  vendor. 

•  Linker:  The  linker  joins  together  the  various  object  modules  and  the  runtime  software  into  an 
executable  module  that  will  run  on  the  target  machine.  As  part  of  this  process,  it  may  make 
adjustments  to  the  code  based  on  the  intricacies  of  the  target  processor. 

•  Configuration  manager:  This  tool  is  used  to  achieve,  at  a  minimum,  configuration  management 
of  both  documentation  and  code. 

•  Target  simulator:  While  devetopment  can  be  accomplished  without  simulators,  they  are  becom¬ 
ing  essential  development  and  productivity  tools.  They  allow  more  development  work  to  be  done 
on  the  host  machine,  as  opposed  to  repeated  and  often  time-consuming  downloading  to  the 
target. 

•  Oownloader:  This  tool  is  used  to  download  the  executable  code  from  the  host  machine  to  the 
target  processor.  Sometimes  downloader  software  is  supplied  by  target  computer  vendors. 


^^While  developnient  can  be  accomplished  (sometimes  with  great  difficulty)  without  debuggers,  symbolic  debuggers  allow  for 
execution  of  software  under  programmer  control.  They  provide  methods  for  stopping  software  execution  at  specific  points  and  for 
examining  and  modifying  data  locations  using  source  code  names. 
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6.3.3.  Optional  Tools:  Action  Plan 

Optional  tools  should  be  evaluated  in  light  of  identified  needs  and  the  tools'  usefulness  in 
supporting  the  software  development  process. 

There  are  many  other  tools  that  are  useful,  but  not  essential,  to  the  software  development  process. 
Several  of  these  are  briefly  explained  in  Table  6-1.  This  table  addresses  only  those  tools  that  are  directly 
a  part  of  the  programming  process;  many  other  tools  (desktop  publishing  and  presentation,  e-mail,  etc.) 
can  also  have  an  impact  on  productivity  throughout  the  life  cycle. 

Before  decisions  are  made  to  acquire  and  develop  additional  tools,  consideration  should  be  given  to: 

•  Size  of  the  software  development  effort:  Small  development  efforts,  such  as  those  ac¬ 
complished  on  a  personal  computer  (PC),  may  not  warrant  additional  tools.  However,  for  large, 
multi-team  efforts,  possibly  involving  geographically  distant  participants  (such  as  the  Army  Com¬ 
anche  helicopter  and  the  Air  Force  F-22  fighter  programs),  tools  and  capabilities  beyond  those 
described  in  Table  6-1  will  be  required,  as  will  significant  management  attention  to  the  develop¬ 
ment  process. 

•  Documentation  requirements:  User  guides  and  online  documentation  should  be  evaluated  for 
availability  and  quality. 

•  Functionality,  interfaces,  methodologies,  and  compatibility:  New  tools  should  be  evaluated 
for  compatibility  with  an  organization's  existing  tools  and  methodologies  and  the  Ada  language 
[233, 1 05, 1 06, 231 , 225].  An  example  Is  design  tools:  Are  they  compatible  with  Ada's  assump¬ 
tions  about  software  organization  such  as  packages?  When  public  domain  tools  are  being  con¬ 
sidered,  the  degree  of  modification  required  must  be  determined. 


6.4.  For  More  Information . . . 

Details  about  validation,  including  commonly  used  Ada  validation  terms,  the  organizational  structure  for 
managing,  coordinating,  and  directing  the  Ada  validation  process,  steps  In  the  process,  and  guidance  to 
DoD  program  managers  on  the  acquisition,  use.  and  maintenance  of  Ada  compilers  are  contained  in  the 
AJPO  validation  procedures  [3].  Additionally,  guidance  for  compiler  evaluators  is  found  in  the  Ada  Adop¬ 
tion  Handbook:  Compiler  Evaluation  and  Selection  [226]  and  for  tool  evaluators  in  Issues  in  Tool  Acquisi¬ 
tion  [233]. 
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Tool 

Purpose 

Source-code  formatter 

Also  known  as  pretty  printer,  these  tools  format  source  code  using 
predefined  coding  conventions,  thereby  ensuring  a  standard  visual  for¬ 
mat.  Since  formatting  conventions  may  differ  between  software  develop¬ 
ment  efforts,  the  formatter  tool  should  allow  an  organization  to  specify  its 
own  conventions.  Sometimes  pretty  printing  is  supplied  as  part  of  com¬ 
piler  services,  as  opposed  to  a  stand-alone  tool  (See  Section  6.2.2.3). 

Object-code  analyzer 

Analyzes  execution  paths  in  object  code.  This  information  can  aid  in  test¬ 
ing  and  determining  which  code  could  be  further  optimized. 

Static  analyzer 

Provides  characteristic  information  about  software  such  as  number  of 
lines  of  code,  number  of  comments,  control  flow  complexity,  and 
measures  of  coding  style.  A  compiler  may  provide  this  information, 
eliminating  the  need  for  this  tool. 

Dynamic  analyzer 

Monitors  and  reports  the  execution  behavior  of  code  so  performance  can 
be  tuned. 

Source-code  cross 
referencer 

Gives  a  cross-referenced  table  specifying  where  symbols  in  the  software 
are  declared  and  used,  and  how  they  are  used.  Some  compilers  provide 
this  information  directly.  A  more  advanced  tool  allows  a  user  to  ’browse* 
online,  moving  automatically  from  the  place  where  a  name  is  used  to  the 
place  where  it  is  defined. 

Syntax-directed  editors 

Assists  in  creating  source  code  by  analyzing  and  checking  for  many 
types  of  errors  as  the  source  code  is  entered.  The  advantage  of  these 
advanced  editors  (also  known  as  language-sensitive  editors)  is  identify¬ 
ing  certain  types  of  errors  early,  without  having  to  process  the  code 
through  a  compiler. 

DOD-STD-2167A 

documentation 

generators 

Supports  the  generation  of  documentation  according  to  the  formats  of 
DOD-STD-2167A  data  item  descriptions  (DIDs).  Often  errployed  in  con¬ 
junction  with  program  design  language  (PDL)  tools  and/or  graphical  pro¬ 
gramming  tools. 

Graphical  programming 
tools 

Allows  software  engineers  to  visualize  the  design  process  and  the  result¬ 
ing  system  design  as  it  develops.  These  tools  are  relatively  new,  but 
progress  in  this  area  has  been  encouraging. 

PDL  processor 

Supports  the  processing  and  documentation  of  software  designs. 

Test  manager 

Helps  organize  and  execute  software  tests,  including  comparing  test 
results  from  previous  runs. 

Module  manager 

Accepts  directions  about  how  to  build  a  system  baseline;  determines 
which  modules  in  a  system  have  been  changed  and  which  nmdules  are 
potentially  affected  by  the  changes. 

Table  6-1:  Optional  Tools 
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7.  Ada  Applicability 


7.1.  Scenarios  for  Ada  Use 

Ada  can  be  used  today  for  applications  that  range  from  infonnation  systems  to  embedded, 
time-critical  applications  and  that  run  on  marlines  from  microprocessors  to  much  larger  com¬ 
puters.  For  severely  time-critical  (i.e.,  hard  real-time)  applications  on  resource-constrained 
machines,  special  care  is  required  in  selecting  appropriate  compilers  and  tools. 

Given  the  wide  spectmm  of  DoD  applications  and  the  wide  variety  of  processors  in  use,  any  evaluation  of 
Ada  applicability  must  address: 

•  requirements  of  the  application  domain,  such  as: 

•  type  of  computers  used  as  the  target  processors 

•  processing  requirements  (real-time,  etc.) 

•  resource  constraints  (memory,  peripheral  equipment,  etc.) 

•  physical  environments  (ground  based,  airborne,  spacebome,  etc.) 

•  maturity  of  software  technologies 

•  capabiiities  of  candidate  target  processors 

•  maturity  and  capability  of  development  organizations 

The  following  paragraphs  briefly  survey  the  current  situation  and  answer  the  question,  "How  and  where 
can  Ada  be  used?" 

Low  Risk: 

•  Applications  that  are  not  time  critical  and  am  on  machines  with  medium  to  large  memory 
capacity.  Such  applications  include  software  tools,  support  software,  simulations,  and  many 
ground-based  applications. 

•  Time-critical,  ground-based  applications  running  on  machines  with  medium  to  large  memory 
capacity  going  into  Immediate  deveiopment. 

Medium  Risk: 

•  Large  command,  control,  communications,  and  intelligence  (C®l)  projects  involving  compiex  in¬ 
terfaces  and  looseiy  coupled  distributed  processing  or  databases.  (See  Section  8.2  for  more  on 
the  topic  of  interfacing  to  commercial  software  packages.) 

•  Time-critical,  embedded  (i.e.,  airbome/spacebome)  applications  going  into  engineering  and 
management  development  (EMD)  in  the  next  2  to  4  years.  This  situation  can  be  made  some¬ 
what  less  risky  by  selecting  target  processors  that  provide  more  Ada  support. 

•  Current  (e.g.,  developing  code)  embedded  time-critical  applications,  such  as 
airbome^pacebome  applications  using  embedded  avionics  processors 

In  any  of  these  medium-risk  scenarios,  program  management  must  make  judgments  about  Ada  tech- 
rK>logy  compared  to  the  schedule  of  the  actual  program.  Consideration  might  be  given  to  including  (and 
funding)  risk  reduction  and/or  technology  insertion  phases  in  the  program,  especially  for  those  projects 
making  first  use  of  Ada. 

High  Risk:  Massively  parallel  systems  and  certain  distributed  systems  (See  Section  7.5). 
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Although  there  are  risks  in  developing  software-intensive  systems,  Ada  has  proven  to  be  the  best  lan¬ 
guage  available  in  many  cases  (such  as  [151]),  and  many  of  the  risks  are  not  language  specific,  but  are 
driven  by  issues  of  complexity  in  interfaces  or  time  criticality.  Ada  provides  a  way  to  enable  good  software 
engineering  and  management  principles  to  be  applied  in  ameliorating  these  risks. 


7.2.  Ada  and  System  Engineering 

System  engineenng  tradeoffs  are  increasingly  reflecting  the  importance  of  software  engineer¬ 
ing  issues  in  developing  systems  today.  Managers  should  develop  action  plans  to  address 
these  tradeoffs  as  part  of  their  risk  management  activities. 

Successful  adoption  of  Ada  depends  not  only  on  the  maturity  of  compilers  and  software  tools,  but  also  on 
system  engineering  analysis  of  the  program  schedule,  hardware  choices,  performance  requirements,  and 
supportability  issues;  these  should  be  mapped  against  Ada  capabilities.  The  program  manager  must 
insure  that  software  tools  are  available  for  the  processors  selected;  joint  selection  of  the  target  computer 
and  support  software  is  the  optimal  approach.  In  the  following  subsections,  various  system  engineering 
situations  are  examined,  and  possible  action  plans  suggested. 

7.2.1.  Absence  of  Compiler:  Action  Plan 

Several  options  are  available  if  no  Ada  compiler  exists  for  the  selected  hardware. 

An  action  plan  for  evaluating  and  selecting  a  compiler  was  presented  in  Section  6.2.3.  If  no  Ada  compiler 
exists  for  the  selected  target  computer: 

1 .  Select  another  target  computer  for  which  Ada  compilers  already  exist,  if  possible.  The  official 
AJPO  list  (October  1992)  contains  270  validated  base  Ada  compilers  of  the  501  total 
validated  Ada  compilers.  Because  Ada  compilers  are  available  for  a  wide  variety  of  com¬ 
puters,  some  choice  is  possible  in  selecting  compilers  for  various  host-target  combinations, 

^  and  it  should  not  be  necessary  to  build  a  completely  new  compiler. 

2.  If  program  cost  and  schedule  allow,  have  a  code  generator  developed  for  the  target  proces¬ 
sor,  building  on  an  existing  compiler.  The  current  trend  is  to  use  commercially  developed 
products  because  of  their  diversity,  lower  cost,  and  quality,  rather  than  developing  a  new 
compiler. 

This  process  of  retargeting  (extending  a  compiler  to  generate  code  for  a  new  target  com¬ 
puter)  is  also  known  as  building  a  new  code  generator  or  compiler  back  end.^  If  the 
manufacturer  of  the  target  processor  provides  a  tool  set  (linker,  loader,  debugger,  assembler, 
etc.),  determine  what  extensions  or  additional  capabilities  may  be  required. 


**7h8  current  list  of  validated  compilers,  including  host  and  target  information,  is  available  in  printed  and  electronic  form  from  the 
Ada  Information  Clearinghouse  and  is  also  published  in  the  Ada-JOVIAL  Newsletter.  See  Appendices  A  and  B  for  further 
information. 

^A  compBor  consists  of  at  least  two  parts  —  the  front  end  and  the  back  end.  The  front  end,  which  is  also  called  the 
machine-independent  portion,  contains  the  components  that  are  independent  of  the  target  computer  and  can  be  used  in  common  for 
many  target  computers.  The  front  end  generally  will  not  have  to  be  modified  during  the  retargeting  process.  The  back  end  contains 
the  components  that  depend  on  the  characteristics  of  the  target  computer  and  therefore  must  be  designed  specifically  for  each 
target  computer. 
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These  activities  are  likely  to  require  the  use  of  program  funds;  there  is  generally  no  DoO-wide 
funding  for  these  efforts.  Retargeting  development  time  should  range  from  9  to  15  montha 
and  cost  from  $750,000  to  $1 ,750,000.  These  estimates  may  vary  depending  on  a  number 
of  factors,  including: 

•  the  requirements  and  technical  objectives  of  the  effort 

•  the  compiler  techrK>logy  used 

•  the  difficulty  of  the  code  generation  task 

•  the  maturity  of  the  compiler  developer 

•  access  to  the  developer  for  resolving  problems 

•  economic  factors  such  as  the  competitive  position  of  the  developers  bidding  for  the 
work  and  the  potential  market  for  the  compiler.  (For  example,  a  compiler  for  a  target 
processor  used  extensively  would  most  likely  cost  less  to  develop  than  a  compiler 
for  an  aged  or  proprietary  processor  that  has  limited  demand  in  the  marketplace.) 

Additional  time  should  be  planned  to  mature  Xhe  newly  retargeted  compiler.  The  time  re¬ 
quired  for  new  or  modified  tools  to  reach  an  acceptable  level  of  maturity  should  also  be 
considered,  as  discussed  in  Section  4.1.3. 

3.  If  these  alternatives  are  not  possible,  consider  the  risk  and  cost  effectiveness  of  using  Ada. 
Consider  filing  a  waiver  requesting  approval  to  use  another  approved  language  if  an  Ada 
development  is  shown  not  to  be  cost  effective. 

7.2.2.  Object-Code  Efficiency:  Action  Pian 

Concerns  about  object<ode  efficiency  can  be  addressed  by  a  number  of  alternative  actions. 

Where  the  code  generated  by  an  Ada  compiler  might  be  an  issue,  either  due  to  its  performance,  quality, 
or  efficiency,  there  are  several  alternatives: 

1 .  Re-analyze  performance  requirements  and  then  plan  and  conduct  an  appropriate  evaluation 
effort.  (See  Section  6.2.2  and  [226, 227, 93, 204].) 

2.  After  sound  engineering  analysis,  avoid  the  use  of  selected  Ada  language  features  that 
cause  or  are  likely  to  cause  difficulty. 

3.  Obtain  a  compiler  that  produces  better  quality  code,  including  optimizations,  for  the  selected 
processor. 

4.  Selectively  use  assembly  language.  Based  on  sound  engineering  analysis  of  system 
throughput  bottlenecks,  code  parts  of  the  system  in  assembly  language.  Note  that  the  com¬ 
piler  in  use  must  support  either  machine  code  inserts  or  pragma!*®  interface  for  assembly 
language.  (For  additional  irrformation  about  mixing  languages,  see  Section  8.4.1 .) 

5.  Alternatively,  fund  modifications  to  an  existing  compiler  to  meet  program-specific  perfor¬ 
mance  or  r  'source  constraints  or  the  development  of  a  new  compiler  that  produces  better 
quality  cou  '  the  selected  processor.  Such  activities  include  improving  the  generated 
object  code,  tailoring  the  runtime  software,  and  adding  additional  debugging  capabilities. 

Work  with  the  compiler  vendor  to  provide  a  series  of  benchmarks  specific  to  the  application 
that  the  compiler  must  handle  with  adequate  performance  as  a  basis  for  accepting  the 
modified  compiler. 


^Pragmas  are  used  to  convey  information  to  the  compiler,  lor  example,  as  an  instruction  to  the  compiler  to  perform  some  special 
action  such  as  compiler  optimization  or  to  interface  to  software  written  in  other  languages.  There  are  two  kinds  of  language 
pragmas:  those  that  are  predefined  in  the  language  and  those  that  are  defined  by  the  compiler  vendor. 
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6.  Add  resources  (such  as  additional  memory)  to  the  selected  target  processor.  However, 
adding  memory  may  require  modifications  and  enhancements  to  the  existing  support  tool  set, 
and  may  have  an  impact  on  weight,  cooling,  power,  and  other  requirements. 

7.  Upgrade  to  a  more  powerful  processor.  While  this  is  in  principle  the  best  solution  for  making 
a  more  evolvable  system,  there  may  be  issues  regarding  processor  qualification  to  military 
standards  ar)d  supportability  after  the  system  has  been  deployed.  Also,  upgrading  to  a  new 
processor  may  require  modifications  and  enhancements  to  the  existing  support  tool  set,  and 
may  have  an  impact  on  weight,  cooling,  power,  and  other  requirements. 

8.  Add  additional  processor(s)  and  decompose  the  software  onto  the  processors.  Concerns 
here  are  the  additional  overhead  and  complexity  of  the  protocols  (more  software)  that  will  be 
needed  for  the  processors  to  exchange  information.  This  processing  load  is  difficult  to  quan¬ 
tify  and  is  further  affected  by  system  requirements  for  fault  tolerance,  multi-level  security,  and 
the  buses  used  to  connect  the  processors.  Adding  additional  processors  may  also  cause 
weight,  cooling,  power,  and  reliability  problems. 


7.3.  Ada  and  Embedded  Processors 

A  wide  variety  of  embedded  processors  exist.  For  many  of  these  processors,  Ada  is  an  ap¬ 
propriate  language  choice.  However,  It  is  generally  not  cost  effective  to  build  or  use  any  high- 
order  language,  including  Ada,  on  processors  with  unusual  architectures,  highly  restricted  in¬ 
struction  sets,  or  very  specialized  purposes. 

Using  any  high-order  language  (HOL),  including  Ada.  may  not  be  cost  effective  or  even  possible  for 
certain  classes  of  processors  since  all  processors  have  varied  capabilities.  Some  processors  are 
designed  and  optimized  for  single  purposes,  while  others  are  intended  for  general-purpose  use.  This 
orientation  directly  affects  which  programming  ianguage(s)  can  be  used  on  a  particular  processor.  Some 
recently  developed  processors  (that  possess  large  storage  capabilities  and  instructions  for  conveniently 
accessing  this  storage)  provide  a  more  attractive  target  for  high-order  languages  (including  Ada)  than  do 
older,  more  resource-constrained  processors. 

Table  7-1  assesses  the  applicability  of  Ada  on  various  processors  based  on  the  following  factors: 

•  Tool  development:  Effort  and  cost  required  in  developing  and  maintaining  compilers  and  sup¬ 
port  tools. 

•  Quality  of  the  resulting  product:  Specifically,  what  kind  of  code  is  generated?  After  the  code  is 
generated,  will  additional  application  and  project-specific  optimization  be  needed? 

•  Effect  on  software  developers:  Does  the  underlying  hardware  help  or  hinder  the  application 
software  developer?  Do  attributes  of  the  target  processor  add  complexity,  lower  productivity,  or 
increase  the  possibility  of  error? 

7.3.1.  Non-Standard  Architectures:  Action  Plan 

When  considering  a  non-standard  architecture,  several  factors  should  be  addressed  in  ad¬ 
dition  to  the  evaluation  of  available  Ada  compilers. 

While  innovative  approaches  to  processor  atxJ  memory  configurations  are  always  encouraged,  prior  to 
adoption; 

1 .  Consider  potential  difficulties  in  hardware  evolution  as  the  system  goes  through  its  opera¬ 
tional  life  cycle. 
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2.  Evaluate  the  impact  on  required  software  support.  The  costs  of  supporting  unique  or  special 
versions  of  software  development  tools  for  non-standard  memory  configurations  over  the 
system  life  cycle  can  be  considerable.  The  program  manager  should  determine  what  special 
tools  (if  any)  will  be  necessary  and  what  modifications  to  existing  tools  will  be  required,  and 
balance  this  against  the  advantages  of  the  proposed  hardware  configuration. 

3.  Consider  the  potential  impact  on  future  competition  if  the  system  design  is  locked  into  rwn- 
standard  or  proprietary  architectures. 


Category 

Description/Explanatlon 

Examples 

Applicable 

General-purpose  32-bit  processors 
characterized  by  large  linear  address 
space  and  rich  instruction  set. 

DEC  Vax  family,  Intel  80486, 80386, 
80960,  Motorola  68040,  68030,  and 
68020,  SPARC,  MIPS  processors 

Applicable  with 
Minor 

Reservations 

General-purpose  16-bit  processors  and 
resource  constrained  32-bit  processors. 
Extended  memory  and  distributed 
machine  applications  might  provide 
minor  problems. 

Intel  80286,  Intel  80166,  Motorola  68010 
and  68000,  MIL-STD-1750A 

AN/UYK-43 

Applicable  with 
Reservations 

Older,  general-purpose  16-bit  proces¬ 
sors,  usually  characterized  by  hardware 
memory  constraints.  Exp)ected  problems 
are  extended  memory  and  distributed 
machine  applications. 

Intel  8086,  MIL-STD-1750A, 

AN/UYK-44,  AN/AYK-14 

Limited 

Applicability 

Special-purpose  machines.  Ada  com¬ 
pilers  are  available  for  some  digital  sig¬ 
nal  processors  and  special-purpose 
processors. 

Digital  signal  processors  (such  as  Tl 

C30  DSP  or  Motorola  96002),  array 
processors 

Not 

Applicable 

General-purpose  8-bit  processors. 

Intel  8088, 8051 , 8031 ,  Motorola  6809 

Table  7*1 :  Ada  on  Various  Processors 


7.4.  Ada  for  Real-Time  Systems 

Ada  has  been  shown  to  be  effective  for  the  implementation  of  real-time  systems.  New  design 
paradigms,  such  as  rate  monotonic  analysis,  have  allowed  Ada  to  address  the  complexity  in 
real-time  systems  design. 

Concerns  have  been  raised  about  Ada's  usefulness  in  programming  real-time  systems.^^  These  con¬ 
cerns,  which  are  somewhat  anachronistic  since  some  compilers  have  solved  these  problems,  fall  into  two 
areas: 

1.  Efficiency 

•  Some  Ada  implementations  do  not  handle  interrupts  with  acceptable  efficiency. 

However,  some  implementations  can  handle  interrupts  with  an  efficiency  equal  to 
assembly  code.  (Usually  this  approach  requires  the  use  of  pragmas.) 


^^Real-time  refers  to  computer  processing  in  which  the  timeliness  of  the  functions  is  as  important  as  the  correctness  of  the 
functions  Real-time  systems  control,  direct,  or  influence  the  outcome  of  an  activity  or  process  in  response  to  the  data  it  receives 
from  the  activity  or  process.  Examples  of  real-time  systems  are  process  control,  target  acquisition  and  tracking,  and  computer-aided 
navigation. 
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•  Some  Ada  implementations  take  too  long  to  switch  from  mnning  one  task  to 
another.^  However,  some  implementations  have  been  very  efficient  in  context 
switching  performance  or  switching  between  tasks. 

•  Code  generated  by  some  Ada  compilers  is  less  efficient  in  time  and  space  than  that 
generated  by  compilers  for  other  languages.  Code  generated  by  Ada  compilers  can 
be  as  efficient  or  more  efficient  than  code  generated  by  compilers  for  other  lan¬ 
guages.  (See  Section  6.2.2.2.) 

2.  Timing  Control 

•  When  a  task  needs  to  execute  at  a  periodic  rate,  it  appears  to  be  difficult  to  control 
the  rate  with  sufficient  accuracy.  Hartstone  benchmark  results  [92]  have  proven  that 
many  Ada  compilation  systems  can  reliably  meet  hard  deadlines. 

•  Ada  tasks  are  scheduled  for  execution  under  control  of  runtime  software  (a 
scheduler  or  executive)  written  by  the  compiler  vendor.  If  this  software  does  not 
meet  the  needs  of  a  particular  real-time  application,  it  may  be  d'rfficult  or  costly  to 
modify.  Most  compiler  vendors  will  tailor  their  runtime  systems  or  make  available 
source  code  for  their  runtime  systems  for  an  appropriate  licensing  fee. 

•  It  can  be  difficult  to  analyze  the  timing  beha\^or  of  a  system  of  Ada  tasks,  and  the 
behavior  can  depend  significantly  on  runtime  software  that  is  not  under  the  direct 
control  of  application  programmers.  Appropriate  analysis  and  benchmarking  tech¬ 
nologies,  such  as  rate  monotic  analysis  [204]  and  Hartstone  [93],  allow  the  timing 
behavior  of  a  system  comprised  of  Ada  tasks  to  be  analyzed. 

These  concerns  generally  apply  to  some  implementations  of  compilers  and  njntime  systems,  not  to  the 
language,  and  do  not  mean  that  Ada  cannot  be  used  for  real-time  systems.  Real-time  systems  have 
been  written  in  FORTRAN  and  JOVIAL,  languages  that  do  not  support  concurrent  processing  directly,  as 
well  as  in  Ada. 

7.4.1.  Real-Time  Systems:  Action  Plan 

Ada  has  been  used  successfully  in  real-time  systems.  Several  actions  can  be  taken  to  aid  in 

using  Ada  for  real-time  systerr^. 

To  ensure  the  successful  use  of  Ada  for  real-time  systems: 

1 .  Assess  the  performance  and  timing  requirements  of  the  proposed  system.  This  may  require 
prototyping  and  benchmarking,  as  well  as  analysis.  Rate  monotonic  analysis  may  be  an 
appropriate  technique  for  use  in  designing  many  real-time  systems  [204], 

2.  Check  that  the  proposed  compiler  efficiently  supports  real-time  features  needed,  such  as 
interrupt  handling  and  context  switching.  If  interrupt  handling  is  not  efficient,  consider  using 
assembly  language  for  interrupt  handling  (which  is  a  small  portion  of  a  system’s  overall 
code).  If  context  switching  is  not  efficient,  consider  selecting  another  compiler  after  a 
thorough  evaluation. 

3.  Design  the  system  correctly.  Analyze  the  required  execution  threads  (or  processing  flows)  for 
each  stimulus  (or  input)  through  to  the  response  (or  output)  and  minimize  the  task  switches 
on  critical  threads.  A  timing  analysis  can  indicate  when  to  combine  Ada  tasks,  as  an  ap¬ 
propriate  number  of  Ada  tasks  leads  to  an  efficient  design.  Rate  monotonic  analysis 

[189]  may  be  an  appropriate  technique  for  performing  timing  analyses  and  evaluating  sys¬ 
tem  design. 


*^Tasks  are  Ada's  way  of  achieving  concurrent  processing. 
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7.5.  Ada  for  Distributed  Systems 

As  with  other  uses  of  Ada,  Ada  should  provide  improved  maintainability  and  reduced  long-term 
costs  when  used  for  developing  distributed  systems. 

Although  no  currently  approved  DoD  language  was  designed  specifically  for  developing  distributed  sys¬ 
tems,  Ada  can  be  used  in  this  domain  [33, 60, 88, 170, 31, 114, 67, 19, 63, 15].  One  way  of  using  Ada  in 
distributed  systems  is  to  write  independent  Ada  programs  that  execute  on  each  node  of  the  system.  The 
software  resident  in  the  various  nodes  communicate  by  a  message-handling  protocol  implemented  out¬ 
side  the  Ada  language.  This  loosely  coupled  implementation  is  typical  of  many  existing  distributed  sys¬ 
tems,  and  Ada  can  be  used  in  the  same  way.  The  advantages  of  using  Ada  instead  of  some  other 
language  are  improved  maintainability  and  reduced  long-term  costs. 

A  second  kind  of  distributed  system  is  a  tightly  coupled  system,  where  multiple  processors  share  an 
address  space.  The  use  of  Ada  for  these  systems  is  possible,  but  brings  increased  risk. 

A  third  kind  of  distributed  system  is  a  massively  parallel  system  for  which  Ada  compilers  are  not  yet 
available,  although  some  vendors  are  working  toward  those  capabilities  [166]. 
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8.  System  Design  and  Implementation  Issues 

8.1.  Designing  for  Portabiiity  and  Reuse 

Ada's  standardization  and  its  language  features  mean  that  Ada  is  especially  suitable  for 
promoting  software  reuse.  However,  Ada  does  not  automatically  make  software  reusable. 

Rather,  Ada  enables  development  of  portable  and  reusable  software. 

8.1.1.  Portability 

Portability  of  software  across  computing  platforms  can  be  enhanced  trough  effective  use  of  Ada. 

Portability  is  the  extent  to  which  software  can  be  moved  without  modification  between  different  computing 
platforms  (hardware,  operating  system).  Portability  can  be  either  at  the  level  of  source  code  (which  must 
be  recompiled  on  the  new  platform)  or  executable  code  (which  can  be  executed  on  the  new  platform). 
Portability  has  traditionally  been  a  significant  problem  due  to  programming  language  (and  dialect) 
proliferation;  some  modification  seems  to  almost  alwaysbe  required  when  porting. 

The  source  of  the  software,  the  development  environment,  execution  environment,  and  application 
domain  have  been  the  key  components  in  assessing  the  portability  of  software.  When  porting  software, 
the  reasonableness  of  the  port  must  be  considered.  For  example,  porting  a  piece  of  code  that  imple¬ 
ments  a  fairly  generic  function  is  often  straightforward,  but  porting  software  that  is  tightly  coupled  with 
particular  hardware  or  operating  system  constraints  is  usually  much  more  difficult. 

As  opposed  to  other  languages,  a  major  benefit  of  Ada  is  that  Ada  is  standardized,  and  compiler  valida¬ 
tion  has  effectively  limited  the  evolution  of  non-standard  language  dialects.  Thus,  Ada  portability  com¬ 
pares  very  favorably  to  other  languages  because  of  language  standardization,  the  modularity  constructs 
of  Ada  (packages),  and  its  abstraction  capabiitties  (e.g.,  types,  attributes),  which  encourage  isolation  and 
localization  of  machine  dependencies.  Ada's  language  standardization  and  compiler  validation  are  impor¬ 
tant  contributions. 

But  compiler  validation  (compliance  with  the  ACVC)  and  language  features  do  nof  guarantee  portability. 
Portability  can  be  compromised  by: 

•  tradeoffs  made  to  maximize  performance 

•  environment-specific  features  (operating  systems  services,  user  interfaces,  database  manage¬ 
ment  system  (DBMS),  etc.)  used 

•  implementation-dependent  features  (data  representations,  capacity  limitations) 

•  poor  attention  to  portability  during  system  design 

Portability  does  not  occur  automatically  through  the  use  of  Ada.  It  must  be  planned,  designed,  and  coded 
into  the  software.  However,  portability  can  provide  substantial  benefits.  In  one  MIS  application,  the  man- 
machine  interface  software  has  been  ported  to  six  different  targets  with  minimal  impact  [214]. 
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8.1.2.  Reuse 


Ada  provides  features  Vtat  can  enhance  reuse  of  software  architectures  and  components. 

Ada  has  helped  overcome  some  of  the  historical  inhibitors  to  reuse.  Ada’s  language  standardization  and 
unique  facilities  such  as  packages,  generics,  and  separate  compilation  have  provided  a  catatyst  for  reuse. 
Ada  allows  interfaces  to  be  precisely  defined  so  functions  performed  by  a  software  unit  are  obvious, 
precise,  and  regulated.  These  capabilities,  if  properly  used,  will  facilKate  the  reuse  of  software  com¬ 
ponents.  However,  Ada  does  not  automaticaiiyvnake  software  reusable;  rather,  facilities  are  available  to 
design  a  component  for  reuse.  Indeed,  programming  for  reuse  may  require  a  higher  level  of  effort  than 
normal  programming  [21]. 

There  are  numerous  successful  instances  of  reuse-based  development  that  have  resulted  in  significant 
cost  savings  and  quality  improvement  for  the  organizations  involved.  These  range  from  commercial 
process  control  applications  to  air  traffic  control  systems  and  advanced  real-time  command  and  control 
systems  [184, 228).  The  French  firm  Thomson  CSF  reports  50  percent  to  70  percent  and  higher  reuse 
rates  in  developing  numerous  air  traffic  control  systems,  entirely  in  Ada,  for  their  various  international 
clients  [228].  Ada  reuse  is  continuing  to  grow  [166]. 

8.1.3.  Designing  for  Portabiiity  and  Reuse:  Action  Pian 

Ada  provides  capabilities  that  can  be  used  to  support  portability  and  reuse  concepts. 

To  achieve  portability  or  develop  reusable  software,  projects  must: 

1 .  State  portability  or  reuse  as  a  design  objective. 

2.  Plan  appropriate  time/budget  (portable/reusabte  systems  may  cost  more  to  develop  initially). 

3.  Localize  implementation  dependencies  (collect  system-dependent  objects/operations  into  as 
few  packages  as  possible). 

4.  Design  for  change.  Group  parts  of  the  system  that  are  expected  to  change  together  using 
Ada  packages. 

5.  Identify  and  enforce  use  of  well-considered  Ada  features  (e.g.,  attributes)  and  style 
guidelines.^^ 

Whenever  possible,  design  every  system  as  if  it  will  have  to  be  ported  to  a  variety  of  configurations 
through  which  the  system  may  evolve  over  a  20-  to  30-year  life  cycle,  given  fixed  budget,  schedule,  arxl 
resource  constraints.  This  is  not  far-fetched,  as  systems  deveioped  today  wiil  be  in  operation  20  years 
from  now,  and  hardware  advances  are  occurring  almost  every  year.  Following  modem  software  en¬ 
gineering  practice,  portable  software  localizes  dependencies  on  the  target  machine  and  insulates  the  rest 
of  the  software  from  those  dependencies.  These  practices  also  improve  the  quality  of  the  software. 

Portability  and  reuse  are  design  goals  that  management  should  plan  for  by  allocating  sufficient  resources 
(time  and  money)  to  development  efforts  to  plan  for  and  meet  these  goals.  Portability  and  reusability  are 
not  free,  but  should  be  given  serious  consideration  in  managing  software  efforts. 


**See  also  Ponability  and  Style  in  Ada  [1 78],  Ada  Quality  and  Style  Guide  |1 38],  and  (96|. 
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8.2.  Using  Ada  with  Other  Standards  and  Protocois 

Ada  interfaces  to  other  systems  and  standards  are  available.  New  implementations  of  inter¬ 
faces  (ior  bindings;  are  continuing  to  emerge.  This  is  a  direction  of  the  future;  while  early 
concerns  regarding  Ada  use  dealt  primarily  with  language  implementations,  attention  is  now 
turning  to  successful  integration  of  Ada  software  in  overall  systems  environments. 

As  Ada  use  becomes  more  common  in  software-dependent  systems,  and  as  requirements  grow,  system 
developers  will  be  faced  with  both  the  benefits  and  problems  of  adopting  more  disciplined  and  integrated 
approaches  to  software  engineering.  It  is  important  that  Ada  applications  be  able  to  effectively  use 
whatever  resources  are  needed  to  produce  a  complete  system.  These  resources  could  include  operating 
systems  or  communications  services,  database  management  systems,  graphics  packages  or  user  inter¬ 
face  management  systems,  or  interfaces  to  COTS  software  or  other  existing  systems.  These  resources 
may  be  formal  standards,  de  facto  standards,  or  commercial  products  that  have  become  widely  available. 

Using  these  resources  from  an  Ada  application  will  frequently  require  that  an  Ada  binding  to  these  stan¬ 
dards  and  protocols  be  developed.  Each  of  these  bindings  is  a  definition  of  a  set  of  services  that  can  be 
provided  to  an  application  and  an  interface  through  which  those  services  can  be  accessed.  For  an  Ada 
program  to  use  these  services,  a  definition  of  the  interface  (or  binding)  must  be  expressed  in  terms  of  the 
Ada  language.  The  application  developer  still  needs  to  have  available  an  implementation  of  that  binding 
to  build  Ada  applicatir  ns. 

Sometimes  a  binding  effort  may  take  place  as  part  of  a  formal  standardization  program  —  with  public 
input  and  representation  from  both  the  Ada  community  and  the  community  most  interested  in  the  stan¬ 
dard.  At  other  times,  a  particular  organization  or  company  may  implement  a  binding  only  lor  a  particular 
product,  Ada  compiler,  application,  etc. 

Foremost  among  these  issues  is  the  reality  that  Ada  is  rtot  often  the  first  choice  for  defining  and  im¬ 
plementing  bindings.  A  troubling  issue  is  that  an  Ada  binding  may  be  issued  later  than  a  C  binding  and 
the  implementation  of  the  Ada  binding  may  even  be  later. 

Program  managers  need  to  be  very  careful  that  they  do  not  over-constrain  their  contractors  by  requiring 
"Ada  for  the  sake  of  Ada"  and  ignoring  sensible,  thorough,  complete  life-cycle  analyses  that  effectively 
demonstrate  when  reuse,  starxfards,  COTS,  or  languages  other  than  Ada  would  provide  a  more  cost- 
effective  life-cycle  solution. 

Numerous  Ada  bindings  exist  (e.g.,  POSIX,  SQL,  X  Window,  GKS,  Motif,  PHIGS)  and  more  are  being 
developed.  The  AJPO  has  completed  a  survey  of  available  bindings  [133].  Reasonable  future  expec¬ 
tations  on  bindings  and  standards  issues  include  continued  and  increased  availability  of  bindings  and 
secondary  standards  for  Ada. 

The  following  sections  address  three  commonly  discussed  bindings:  POSIX,  SQL,  and  the  various 
graphics  and  window  system  bindings. 
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8.2.1.  POSIX  Ada  Bindings 

Ada  bindings  to  POSiX  have  been  standardized,  and  Ada  bindings  to  POSiX  reai-time  exten¬ 
sions  are  being  developed. 

The  Portable  Operating  System  Interface  for  Computer  Environments  (POSIX)  is  an  international  stan¬ 
dard  for  operating-system  interfaces  [149].  POSIX  is  defined  as  a  full  set  of  standards,  including  a  base 
standard  (ISO/IEC  9945-1:1 990/IEEE  Std.  1003.1-1990)  and  several  functional  extension  standards 
covering  such  topics  as  real-time  (IEEE  Std  1003.4/4a),  shell  and  utilities,  and  supercomputing.  The  base 
POSIX  interface  standard  is  derived  from  a  variety  of  Unix  specificatbns  and  implementations. 

The  Ada  POSIX  Standards  Working  Group  (IEEE  1003.5)“  is  developing  two  Ada  interface  standards: 

1 .  Ada  Interface  to  base  POSIX:  The  Ada  binding  to  the  POSIX  system  services  has  been 
approved  as  an  IEEE  Standard  (IEEE  Std.  PI 003.5-1992). 

2.  Real-time  Interfaces:  A  follow-on  project,  IEEE  Pi 003.20,  is  defining  Ada  language  inter¬ 
faces  to  the  Pl003.4/4a  real-time  POSIX  extensions.  Work  commenced  in  October  1991 . 

The  base  POSIX  Ada  binding  document  defines  the  set  of  standard  Ada  83  package  specifications  and 
provides  English  text  describing  the  semantics  of  those  packages.  This  binding  definition  covers  the  set 
of  system  services  defined  in  POSIX  1 003.1 ,  including  files,  directories,  processes,  and  signals.  It  also 
includes  an  interpretation  of  some  Ada  features  (e.g.,  TEXT_IO)  In  a  POSIX  context.  It  does  not  cover 
facilities  covered  in  other  POSIX  documents  (e.g.,  real-time,  security,  system  administration,  and  network¬ 
ing).  Several  vendors  are  planning  implementations  of  the  Ada  binding.  In  general,  these  implemen¬ 
tations  will  be  compiler  specific,  as  some  features  of  the  binding  require  cooperation  from  the  compiler 
and  Its  runtime. 

9.2.2.  SQL  Bindings 

Several  approaches  ta  using  Ada  with  the  SQL  interface  to  database  management  systems 
have  resulted  In  emerging  standards. 

The  Structured  Query  Language  (SQL)  is  an  Interface  to  database  management  systems.  There  has 
been  much  interest  in  Ada  bindings  to  SQL,  as  only  bindings  for  the  COBOL,  FORTRAN,  Pascal,  and 
PU1  languages  were  included  in  the  SQL  standard  [14].  The  Ada  binding  is  in  the  current  ISO  SOL2 
standard  (ISO  9075:1992). 

The  SEI  has  investigated  the  problem  of  binding  the  Ada  programming  language  with  the  SQL  database 
language  [95].  The  solution  to  this  problem  was  the  specification  of  the  SQL  Ada  Module  Extension 
(SAME),  an  architecture  for  Ada  SQL  applications  that  emphasizes  software  engineering  principles  [115]. 
The  SQL  Ada  Module  Description  Language  (SAMeDL)  [52]  facilitates  the  construction  of  Ada  SQL  ap¬ 
plications  having  the  SAME  architecture.  The  ISO  Ada  working  group  is  preparing  the  SAMeDL  for 
standardization  [213].  This  process  is  due  to  be  completed  in  1993. 


‘’’See  Appendix  B.2  for  contact  information. 
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8.2.3.  Graphics  and  Window  System  Bindings 

Ada  bindings  have  been  impiemented  for  a  number  of  graphics  or  windowing  systems  stan¬ 
dards  that  are  in  widespread  use. 

In  implementing  graphical  user  interfaces  (GUI),  several  graphics  or  windowing  system  standards  are 
often  used.  These  include  Graphical  Kernel  System  (GKS),  Programmer's  Hierarchical  interactive 
Graphics  System  (PHIGS),  and  the  X  Window  System.  Various  Ada  bindings  have  been  implemented  for 
these  standards. 

For  example,  the  Ada  binding  to  GKS,  which  is  a  standard  library  of  subroutines  for  an  application 
programmer  to  incorporate  within  a  program  to  produce  and  manipulate  graphical  images,  is  an  ANSI/ISO 
standard  (ANSI  document  #X3. 124.3/ISO  8651-3).  The  Ada  binding  to  PHIGS,  which  is  a  graphics  sys¬ 
tem  designed  to  support  computer  graphics  applications  that  are  highly  dynamic  and  interactive,  is  also 
an  ANSI/ISO  standard  (ANSI/iSO  9593-3  -  PHIGS/Ada  binding).  Work  is  undenvay  to  develop  a  binding 
to  the  enhanced  PHIGS  —  PHIGS  PLUS.  The  PHIGS  PLUS/Ada  binding,  when  approved,  will  be 
published  as  an  amendment  to  the  PHIGS/Ada  binding. 

The  X  Window  System  is  a  network-transparent  window  system.  It  supports  one  or  more  screens  con¬ 
taining  overlapping  windows  or  subwindows.  X  Window  systems  are  typically  used  with  either  the  OSF 
Motif  (Open  Software  Foundation/Motif)  or  the  Open  Look  graphical  user  interfaces.  Numerous  Ada  bind¬ 
ings  or  Ada-based  user  interface  toolkits  interfacing  to  X  Window  or  to  its  toolkit  libraries  have  been 
implemented. 


8.3.  Using  Special-Purpose  Languages 

Ada  is  better  for  some  applications  than  for  others.  In  some  cases,  spet^al-purpose  languages 
may  still  be  appropriate  for  specific  applications. 

Special-purpose  (or  problem-oriented)  programming  languages  have  historically  been  developed  to  sup¬ 
port  highly  specialized  applications.  As  such,  there  is  a  large,  mature  base  of  software  in  these  languages 
and  application  areas  that  may  take  several  years  for  Ada  to  replace.  The  languages  (and  application 
areas)  considered  below  are: 

•  ATLAS  for  automatic  test  equipment  applications 

•  Simulation  languages  such  as  SIMSCRIPT  and  GPSS 

•  Artificial  Intelligence  languages  such  as  LISP 

•  “Fourth-generation”  languages  for  database  and  interactive  applications 

8.3.1.  ATLAS 

Although  DoD  policy  had  specified  that  Ada  Is  preferred  (but  not  required)  as  the  language  to 
be  used  for  hardware  unit  under  test  (UUT)  equipment  [78],  current  DoD  policy  [79]  authorizes 
the  use  of  ATLAS  in  automatic  test  equipment. 

ATLAS  [131]  is  a  programming  language  designed  specifically  for  use  in  controlling  test  equipment.  As 
such  it  is  an  acceptable  and  often  appropriate  choice  for  use  in  automatic  test  equipment.  ATLAS  is  a 
DoD-approved  language  [77]  for  programming  automatic  test  equipment  (ATE).  It  contains  special  fea¬ 
tures  that  allow  the  direct  expression  of  wave  forms,  timing  requirements,  and  stimulation  patterns,  all  of 
which  are  critical  to  the  development  of  this  type  of  software. 
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AKhough  the  functionality  of  ATLAS  could  be  supported  in  Ada  (by  writing  Ada  subprograms  that  have 
functional  capabilities  similar  to  those  provided  by  ATLAS  commands),  much  code  provided  directly  by 
ATLAS  would  have  to  be  specially  written  if  Ada  were  used.  While  much  of  this  software  could  be  reused 
in  subsequent  applications,  the  initial  development  cost  would  be  significantly  higher  if  the  required 
software  were  not  already  available  in  Ada.  In  addition,  software  written  in  ATLAS  may  be  more  readable 
by  test  engineers  than  equivalent  software  written  in  Ada,  simpiy  because  ATLAS  has  special  language 
constructs  that  are  particularly  suited  to  expressing  ATE  algorithms. 

On  the  other  hand,  Ada's  superior  capabilities  for  giving  large  software  systems  an  understandable  struc¬ 
ture  make  it  a  preferable  choice  for  large,  complex  ATE  projects.  There  is  ongoing  work  in  the  IEEE 
Ada-Based  Environment  for  Test  (ABET)  standards  development  arena  that  will  take  advantage  of  Ada 
programming  and  implementation  features  while  retaining  the  high-level.  Unit  Under  Test  (UUT)  test 
specificatfon  aspects  of  ATLAS  [165, 169).  This  standard  (IEEE  1226)  is  planned  for  release  in  1994. 

8.3.2.  Simulation  Languages:  SIMSCRIPT  and  GPSS 

For  simulation  programming,  it  may  be  preferable  to  use  one  of  the  special-purpose  simulation 
languages;  nevertheless,  simulation  software  is  being  written  effectively  in  Ada. 

SIMSCRIPT  and  GPSS  are  examples  of  special-purpose  languages  for  programming  simuiations.  For 
example,  these  languages  allow  a  software  developer  to  sample  from  various  probability  distributions, 
specify  when  certain  events  of  interest  to  the  simulation  are  to  occur,  and  indicate  what  data  are  to  be 
gathered  when  the  events  occur.  They  also  have  special  features  that  help  In  reporting  results. 

Effective  simuiation  software  has  been  written  in  Ada.  Ada  has  been  used  extensively  in  the  flight 
simulator  domain.^^  Since  Ada  has  no  language  constructs  or  predefined  subprograms  specially 
designed  for  simulation  programming,  simulation  developers  will  Initially  have  to  write  more  code  to 
provide  the  same  special-purpose  simulation  language  facilities  in  Ada.  Ada  software  can  be  written  to 
support  simulation  programming,  and  many  of  Ada's  initial  applications  have  been  in  the  simulation  arena. 
Once  written,  these  routines  can  be  used  by  future  simuiation  efforts. 

8.3.3.  Artificial  Intelligence  Languages:  LISP 

Once  an  artificial  Intelligence  (Al)  technique  is  well  understood  and  is  to  be  engineered  into  an 
application.  It  may  be  appropriate  to  use  Ada  as  the  language  for  Implementing  the  operational 
apf^lcation.  For  Al  research,  LISP  is  more  appropriate. 

LISP  is  the  language  of  choice  for  artificial  intelligence  (Al)  research.  Like  Ada  (and  unlike  ATLAS, 
SIMSCRIPT,  or  GPSS),  LISP  is  a  general-purpose  language.  LISP  programming  is  typically  done  in  a 
rich  programming  support  environment;  the  programming  support  tools  (which  are  written  in  LISP)  are  a 
strong  reason  for  continued  interest  in  LISP. 

LISP  is  used  for  Al  research  applications  because  LISP  software  is  easy  to  change.  Ease  of  change  is 
important  in  Al  research,  where  the  objective  is  usualiy  to  discover  how  to  make  a  computer  perform  a 
task  that  is  not  well  understood.  LISP  offers  a  high  degree  of  flexibility  to  small  teams  of  skilled 


‘'See  (157)  for  one  such  example  that  has  had  wide  impact  in  this  community. 
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developers  working  on  prototypes,  but  that  very  flexibility  may  be  inappropriate  for  a  large  team  of 
programmers  facing  a  significant  engineering  activity. 

Ada  supports  a  different  view  of  software  development,  which  says  that  changes  can  be  hard  to  imple¬ 
ment  correctly  and  should  be  done  using  a  language  that  helps  detect  inconsistencies  in  a  changed 
system,  and  supports  administrative  control  over  the  change  process.  This  viewpoint  is  appropriate  for 
large,  long-lived  systems,  which  may  have  several  versions  to  be  managed  and  maintained. 

These  viewpoints  are  less  clear  when  moving  from  research  to  operational  applications.  Although  LISP 
has  been  used  extensively  for  Al  research,  if  the  result  of  some  Al  research  is  to  be  used  in  an  opera¬ 
tional  system,  LISP  may  no  longer  be  the  most  appropriate  language.  For  example,  making  software 
easy  to  change  has  a  price  —  LISP  software  is  typically  less  efficient  in  the  use  of  time  and  space  than  is 
Ada.  In  addition,  because  LiSP  is  easy  to  change,  it  is  easy  to  change  incorrectly;  such  errors  are  usually 
easy  to  fix  during  the  research  phase  but  difficult  to  fix  when  a  system  is  widely  distributed  and  in  opera¬ 
tional  use. 

Depending  on  a  sound  engineering  study  of  an  application,  LISP  may  be  too  inefficient  for  operational 
use.  If  so,  the  Information  developed  during  the  research  phase  can  be  used  to  design  a  more  efficient 
(albeit  less  easily  changed)  system  that  can  be  used  operationally.  In  such  cases,  it  will  probably  be 
better  to  implement  the  operational  system  using  Ada.  On  the  other  hand,  LISP  may  continue  to  be  an 
appropriate  choice  for  an  operational  system  if: 

•  time  and  space  efficiency  are  not  critical  or  the  target  computer  is  specially  designed  to  execute 
LISP  code  efficiently; 

•  functional  changes  will  be  required  frequently  (e.g.,  at  least  monthly),  but  the  nature  of  the  re¬ 
quired  changes  cannot  be  predicted  easily;  and 

•  sufficient  safeguards  are  taken  to  ensure  that  changes  are  made  correctly  or  to  minimize  the 
effect  of  an  incorrect  change. 

8.3.4.  Fourth-Generation  Languages 

Fourth-generation  programming  languages  are  cost  effective  when  used  appropriately.  Their 
main  drawbacks  are  limited  domain  of  usability  (they  cannot  satisfy  the  needs  of  some  ap¬ 
plications).  slower  performance,  andpossit^e  dependence  on  a  single  vendor. 

Fourth-generation  languages  (4QL),  which  include  application-specific  database  languages,  spread¬ 
sheets,  and  non-procedural  languages,  are  not  direct  descendants  of,  and  not  necessarily  improvements 
over,  third-generation,  general-purpose  languages.  They  might  better  be  called  program  generators  or 
application-specific  tools  and  are  designed  for  a  limited  domain  of  use. 

If  an  application  is  well  matched  to  a  fourth-generation  language,  the  cost  of  realizing  the  application  can 
be  significantly  less  expensive  than  programming  it  in  a  general-purpose  language  such  as  Ada.  For 
example,  spread  sheets  are  routinely  used  to  develop  in  hours  applications  that  would  require  days  in  a 
general-purpose  language  like  Ada. 

While  fourth-generation  languages  offer  significant  advantages  in  productivity  and  rapid  prototyping,  there 
are  some  significant  disadvantages  to  consider; 
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•  Limited  domain  of  applicability:  Fourth-generation  languages  are  quite  effective  when  used  for 
appropriate  application  domains,  but  the  area  of  appropriate  use  is  bounded  —  if  some  part  of  an 
application  lies  outside  the  domain  of  a  fourth-generation  language,  serious  performance 
penalties  may  result,  or  the  language  may  not  be  usable  at  all.  A  project  might  initially  have 
great  success  using  a  fourth-generation  language,  only  to  discover  later  that  certain  require¬ 
ments  cannot  be  met  successfully  and  a  completely  new  approach  is  required,  in  addition, 
fourth-generation  languages  to  date  have  been  most  effective  when  applied  to  small  projects; 
large  projects  have  presented  additional  difficulties. 

•  Performance:  An  application  using  a  fourth-generation  language  usually  runs  slower  than  an 
equivalent  solution  written  in  a  high-order  language.  This  performance  degradation  may  be  an 
acceptable  tradeoff  in  some  applications,  given  the  increase  in  programming  productivity,  but 
fourth-generation  languages  are  usually  not  well  suited  to  applications  that  stretch  the  perfor¬ 
mance  capabilities  of  a  system. 

•  Vendor  dependence  or  lack  of  control:  Fourth-generation  languages  tend  to  be  commercial 
products  and  are  thus  highly  susceptible  to  the  pressures  of  the  marketplace.  If  an  application  is 
meant  to  have  an  extended  life  cycle,  the  product  may  change  and  become  incompatible  or  even 
disappear. 

Chances  of  success  with  a  fourth-generation  language  are  good  if  the  requirements  fall  within  the  domain 
of  the  particular  fourth-generation  language.  If  this  criterion  is  not  met,  there  is  considerable  risk  that  the 
effort  will  result  in  failure. 

8.4.  Mixing  Ada  with  Other  Languages 

Mixing  Ada  with  other  languages  is  possible,  provided  consideration  is  given  to  technical  and 
management  issues.  On  the  other  hand,  "automatic"  translation  of  code  written  in  other  lan¬ 
guages  should  be  approached  cautiously. 

The  question  of  mixing  languages  is  important  to  managers  of  both  new  developments  and  existing 
operational  systems  (post-deployment  software  support).  Among  the  questions  of  interest  are: 

•  Should  Ada  be  used  in  the  next  upgrade? 

•  Is  it  appropriate  to  develop  and  maintain  a  system  partly  in  Ada  and  partly  in  some  other  lan¬ 
guage,  thereby  creating  a  hybrid  system? 

The  following  criteria  can  be  used  to  answer  these  questions: 

•  Can  the  Ada  code  interface  with  code  written  in  another  language? 

•  Is  the  replaced  portion  relatively  independent  of  the  rest  of  the  system? 

•  Is  much  of  the  system  being  replaced? 

•  If  a  hybrid  system  seems  inappropriate,  should  the  system  be  rewritten  entirely  in  Ada,  even 
though  large  portions  of  code  would  not  otherwise  have  to  be  changed? 

8.4.1.  Interfacing  Ada  Code  with  Other  Languages 

When  mixing  Ada  with  other  languages,  several  technical  issues  should  be  addressed. 

Among  the  issues  to  be  considered  in  attempting  to  interface  Ada  with  other  languages  are: 

•  Can  the  Ada  code  call  subroutines  written  in  other  languages?  Alternatively,  does  the  new  Ada 
code  have  to  be  called  from  the  rest  of  the  system?  For  example,  can  a  COBOL  or  JOVIAL 
compiler  generate  code  to  call  Ada  subprograms? 
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•  What  kind  of  data  have  to  be  processed  by  both  the  Ada  code  and  the  rest  of  the  system?  Can 
the  data  be  represented  in  a  way  that  Is  acceptable  to  both  languages? 

•  How  much  redundant  or  unused  mntime  support  software  will  be  present  in  the  completed  sys¬ 
tem?  Can  the  runtimes  for  the  languages  co-exist  efficiently? 

The  following  subsections  present  further  details. 

8.4.1 .1.  Subroutines  Not  Written  In  Ada 

Efficiently  interfacing  Ada  with  another  language  requires  the  ability  to  call  subroutines  written 
in  other  languages. 

Subroutines  written  in  COBOL,  JOVIAL,  assembly,  or  some  other  language  can  be  called  from  the  Ada 
software  if  an  Ada  compiler  supports  the  pragma  interface  for  those  languages.  If  this  pragma  is  not 
supported  for  the  language  and  compiler^^  of  interest,  the  cost  and  schedule  implications  of  obtaining 
support  should  be  determined.  Similarly,  if  the  existing  code  must  call  Ada  subprograms,  modifications  to 
the  compiler  for  the  other  language  may  also  be  necessary. 

However,  some  vendors  have  implemented  multi-language  integrated  environments  whereby  any  of  their 
supported  languages  (Ada,  JOVIAL,  FORTRAN,  etc.)  can  call  subprograms  in  any  language. 

Another  strategy  is  providing  explicit  implementation-dependent  \mpotVexpon  capabilities.  From  any 
vendor-supported  language,  one  can  access  subprograms  and  (in  some  cases)  data  objects  from 
programs  in  other  languages.  There  is  a  growing  request  for  a  more  standard  interface  to  achieve  this. 

8.4.1 .2.  Compatible  Data  Representation 

Compatibility  of  data  representation  is  a  critical  although  often  overlooked  factor  in  interfacing 
with  another  language.  Incompatibility  can  lead  to  inefficient  code  or  difficulties  in  implement¬ 
ing  an  interface. 

Another  requirement  for  implementing  a  hybrid  system  is  assuring  the  compatibility  of  data  representation 
between  Ada  and  the  other  language.^  The  data  interface  between  the  languages  must  be  specified 
and  controlled,  just  as  it  is  between  processors  and  buses.  Key  questions  program  managers  must 
answer  include: 

•  What  data  will  be  interchanged  between  the  Ada  and  non-Ada  portions  of  the  system? 

•  Will  the  storage  layout  for  these  data  be  the  same  for  both  languages?  If  not,  can  it  be  made  the 
same?®* 

•  If  the  storage  layout  cannot  be  made  identical,  how  will  efficiency  be  affected? 


“The  interface  is  created  to  a  speoffccompiier  —  for  example,  a  specific  FORTRAN  compiler,  not  to  just  any  FORTRAN 
compiler. 

“For  example,  arrays  in  FORTRAN  are  typically  stored  differently  from  arrays  in  Ada.  So.  although  a  FORTRAN  matrix  inversion 
routine  may  be  called  from  Ada,  the  FORTIN  language  will  view  tfw  matrix  as  though  its  data  are  arranged  differently  from  the 
Ada  view  and  will  produce  incorrect  results.  (This  kind  of  incompatibility  is  not  uncommon  between  languages.)  On  the  other  hand, 
if  the  Ada  implementation  is  designed  to  support  interaction  with  FORTRAN  software,  it  may  store  arrays  r  the  manner  required  by 
FORTRAN,  or  it  may  give  a  means  to  specify  how  data  are  represented  so  no  problem  will  arise. 

“While  the  Ada  language  provides  special  features  (rep^entation  Ciduses  and  implementation-depertdent  pragmas)  that  allow 
software  developers  to  specify  data  storage  layouts  in  detail,  at  present  not  all  Ada  compilers  adequately  support  these  facilities 
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8.4.1 .3.  Redundant  Runtime  Support 

Using  two  languages  may  require  examining  how  the  functionally  redundant  runtime  software 
environments  will  co-exIst. 

Runtime  support  for  a  language  is  the  code  needed  to  Implement  its  complex  features.  If  a  system 
contains  code  written  in  two  or  more  languages,  the  runtime  support  code  for  both  languages  will 
generally  be  needed.  For  example,  suppose  a  system  is  written  in  COBOL,  which  has  extensive  I/O 
support  facilities.  Suppose  the  unmodified  portion  of  the  original  system  continues  to  use  COBOL's  I/O 
facilities,  and  the  replaced  portion  uses  Ada's  I/O  facilities.  Runtime  support  code  will  be  needed  for  both 
the  Ada  and  COBOL  portions  of  the  system,  which  can  be  unnecessarily  expensive  in  space.  If,  instead, 
the  nx)difications  were  designed  so  that  all  I/O  processing  were  done  by  the  COBOL  code,  then  Ada's  I/O 
runtime  support  code  need  not  be  loaded.  The  savings  in  space  could  be  significant  in  a  resource-limited 
system. 

Although  it  may  not  be  necessary  to  load  Ada's  runtime  support  for  I/O,  some  less  mature  compilers  may 
load  it  anyway.  The  extent  to  which  a  compiler  loads  only  the  needed  ointime  support  software  is  an 
important  factor  in  deciding  whether  it  is  feasible  or  cost  effective  to  write  just  a  portion  of  a  system  in 
Ada.  Only  a  detailed  analysis  will  provide  answers  to  these  important  factors. 

Key  questions  regarding  runtime  support  include: 

•  Can  the  runtime  environments  co-exist?  Various  languages  assume  different  system  memory 
models  or  have  different  paradigms  regarding  the  scheduling  of  tasks.  This  type  of  incompatibility 
may  cause  unpredictable  system  behavior. 

•  How  much  runtime  support  code  is  associated  with  the  use  of  particular  Ada  language  features? 

•  Is  runtime  support  software  loaded  whether  or  not  it  is  actually  needed? 

•  Is  some  of  the  runtime  support  essentially  the  same  for  both  Ada  and  the  other  language?  If  an 
overlap  is  significant.  Is  it  necessary  to  use  the  associated  Ada  features? 

8.4.2.  isolating  Subsystems 

To  minimize  lariguage  lncorr^)atlblllty,  the  portion  of  the  system  that  Is  written  In  one  language 
should  be  relatively  Independent  of  the  portion  written  In  another  language. 

It  may  be  appropriate  to  write  a  new  portion  of  a  system  in  Ada  if  the  new  portion  is  relatively  isolated 
from  the  unmodified  portion.  Two  examples  where  Ada  might  be  successfully  introduced  are: 

•  DBMS/flle  system  Interfaces:  Suppose  the  unnfK)dified  portion  of  a  system  is  a  database 
management  system  (DBMS)  written  in  COBOL  or  purchased  from  a  vendor  (so  its  source  code 
is  not  available).  If  the  remainder  of  the  system  consists  of  software  that  accesses  the  DBMS 
and  processes  the  results  of  DBMS  queries,  then  calls  to  the  DBMS  can  probably  be  written  as 
easily  in  Ada  as  in  any  other  language. 

•  Distributed  ^sterns:  On  a  distributed  system,  it  should  be  possible  to  replace  the  code  that 
exists  on  the  individual  processor  node(s)  as  long  as  the  system-wide  interfaces  are  maintained. 
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8.4.3.  Replacing  the  Whole  System 

R>ssible  indicators  that  a  system  shouid  be  totally  reimplemented  in  Ada  include  continual 
trouble  reports,  significant  software  change,  or  new  target  hardware. 

If  a  system  is  operating  smoothly,  replacing  that  system  just  for  the  sake  of  having  it  in  Ada  is  generally 
not  recommended.  However,  there  are  several  rules  of  thumb  that  may  indicate  the  need  for  a  system 
replacement.  Assuming  the  availability  of  tools  for  the  target  processor,  Ada  shouid  be  the  replacement 
language  if  any  of  the  following  situations  exist; 

•  Poor  overall  system  reliability;  The  existence  of  unresolvable  trouble  reports,  significant  dif¬ 
ficulties  in  making  corrections  or  enhancements,  or  an  increase  in  new  bug  repxsrts  after 
correction/enhancement  activity  may  indicate  fundamental  system  structure  and  reliability 
problems. 

•  Significant  software  change;  Software  change  can  be  manifested  both  individually  and 
cumulatively.  For  example,  a  significant  individual  change  would  require  changing  more  than 
one-third  of  the  system  at  any  one  time,  with  the  changes  spread  throughout  the  system.®® 

Cumulative  sets  of  changes  amounting  to  two-thirds  from  significant  baseline  also  must  be 
managed  carefully.  While  difficulties  may  not  yet  be  aii^arent,  such  a  degree  of  change  rTK>st 
likely  indicates  a  structure  that  is  becoming  increasingly  trail. 

•  Hardware  replacement;  Hardware  upgrade  or  replacement  provides  an  opportunity  to  also 
upgrade  the  software  design  to  take  advantage  of  new  hardware  capabilities.  In  general,  old 
software  running  on  new  hardware  may  not  take  advantage  of  improved  hardware  capabilities 
such  as  additional  memory  and  graphical  display  capabilities.  As  such,  maximum  performance 
improvement  will  not  be  achieved. 

8.4.4.  Translating  Languages 

Automatic  translation  from  one  programming  language  to  another,  while  an  inUiguing  idea, 
should  be  approached  cautiously. 

Automatic  translation  (through  the  use  of  computer-based  language  translation  tools)  of  existing  code  into 
Ada  is  sometimes  proposed  when  an  existing  system  is  upgraded.  While  a  number  of  translation  systems 
exist,  and  translation  offers  the  possibility  of  getting  something  running  quickly,  which  may  be  very  ap¬ 
pealing  in  today's  fiscal  climate,  there  are  significant  problems  and  issues  to  be  considered  before  taking 
this  approach; 

•  Degree  of  translation;  There  are  always  some  inherent  incompatibilities  between  any  two  lan¬ 
guages.®®  Not  all  constructs  in  other  languages  can  be  translated  automatically  to  Ada  with 
complete  accuracy.  A  good  translation  system  will  flag  possible  mistranslations  so  they  can  be 
manually  inspected.  If  the  existing  software  contains  many  problematic  constnjcts,  much  manual 
effort  will  be  required  to  detect  and  fix  possible  mistranslations. 

•  Loss  of  software  engineering  benefits:  The  translated  code  will  most  likely  be  more  difticult  to 
maintain  than  the  original  software  and  certainly  more  difficult  to  maintain  than  a  system 
designed  and  written  in  Ada  from  the  start.  Two  example  problem  areas  are: 


^^DoD  poliqr  (79]  requires  that  Ada  be  used  for  major  software  upgrades  of  existing  systems.  A  m2yor  software  upgrade  is  the 
redesign  or  addition  of  more  than  one-third  of  the  software. 

**Some  languages,  notably  FORTRAN,  have  many  different  dialects,  which  makes  translating  even  between  diaiects  of  the  same 
language  difficult. 
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•  Readability:  Automatic  translators  may  generate  strange,  non-descriptive  variable 
names  that  decrease  understandability  of  the  code. 

•  System  structure:  Ada  allows  subprograms  and  data  to  be  logically  organized  into 
packages,  which  improve  software  understandability  and  nfK>difiability  and  allow  a 
software  developer  to  express  intent  more  fully  than  in  other  languages.  If  such  a 
grouping  is  not  present  in  the  original  system,  an  automatic  translation  system  cannot 
provide  it. 

•  Special  routines:  Depending  on  the  language  being  translated,  there  may  be  special  functions 
and  capabilities  such  as  those  provided  by  the  runtime  system  that  are  rK>t  directly  translatable. 
These  special  functions  and  capabilities  may  require  that  significant  new  code  be  written  to 
mimic  them  in  the  new  language,  at  unknown  consequences  in  program  schedule  and  perfor¬ 
mance  of  the  resulting  software. 

•  Testing:  Translation  does  not  guarantee  that  the  resulting  code  wili  function  in  a  manner  com¬ 
parable  to  the  original  code.  For  example,  comparable  language  constructs  may  nof  be  im¬ 
plemented  with  comparable  efficiency.  In  addition,  the  translated  code  may  stress  the  compiler  in 
unusual  ways,  revealing  new  compiler  bugs.  In  short,  rigorous  functional  and  performance  test¬ 
ing  are  required  on  the  translated  code,  if  acceptance  tests  exist  for  the  original  system,  they 
should  be  used. 

In  summary,  language  translation  must  be  viewed  as  a  risky,  short-term  proposition  that  will  yield  results 
of  unknown  quality.  Reengineering,  redesigning,  and  recoding  the  system  in  Ada  or  interfacing  newly 
written  Ada  code  with  the  current  implementation  are  much  preferred  approaches. 

If  a  translation  strategy  is  being  considered,  an  in-depth  investigation  of  commercial  and  public  domain 
translators  is  strongly  suggested  as  part  of  the  feasibility  study.  This  investigation  should  use  a  robust  set 
of  test  cases  and  benchmarks  that  are  typical  of  the  particular  application.  These  benchmarks  should 
also  be  used  to  identify  the  amount  of  rework  remaining  after  translation  to  fix  problems  and  successfully 
complete  regression  testing. 


8.5.  For  More  Information . . . 

The  following  resource  recommendations  are  intended  as  an  initial  starting  point  for  those  seeking  more 
information  about  the  topics  in  this  chapter. 

Reuse 

•  Reuse:  Where  to  Begin  and  Why  (1 22] 

•  An  Organized,  Devoted,  Project-Wide  Reuse  Effort [37] 

•  Software  Reuse:  Managerial  and  Technical  Guidelines  [123] 

•  STARS  Reuse  Concepts  [210] 

Portability 

•  Ada  Quality  and  Style  Guide  [138] 

•  Portat^iity  and  Style  in  Ada  [1 78] 

•  The  Myth  of  Portability  in  Ada  [96] 

Ada  Bindings 

•  Available  Ada  Bindings  [133] 
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9.  From  Ada  83  to  Ada  9X 


Ada  83  is  in  use  today,  and  a  ianguage  revision  process  leading  to  a  revised  language  stan¬ 
dard  (Ada  9X)  is  ongoing.  Among  the  changes  to  be  incorporated  in  the  Ada  9X  revisions  of 
ffie  Ada  language  standard  are  irrprovements  in  object-oriented  programming,  programming 
in  ffie  large,  and  real-time  capabilities.  Ada  9X  is  planned  to  be  standardization  in  late  1994 
¥vith  validated  compilers  becoming  available  following  standardization. 


9.1.  Ada  Language  Revision  Process 

All  standards  must  be  periodically  reaffirmed,  revised,  or  allowed  to  lapse.  The  Ada  9X  effort  is 
making  such  a  set  of  revisions  to  the  Ada  language. 

Part  of  the  development  arKf  maturation  embodied  in  an  international  standard  is  the  process  by  which 
standards  organizations  (such  as  ISO  or  ANSI)  require  that  each  standard  be  periodically  reaffirmed, 
revised,  or  allowed  to  lapse.  This  is  not  unique  to  Ada;  all  standards  (including  standardized  languages) 
must  undergo  this  process  periodically. 

The  Ada  language  standard  [13]  was  published  in  1983.  In  1988,  it  was  recommended  that  the  Ada 
standard  be  revised.  Subsequently,  the  Ada  9X  Project  Office^^  was  established  and,  in  early  1989,  an 
Ada  9X  Project  Plan  [11]  was  put  into  place. 

DoO,  NIST  (because  Ada  is  also  a  government  standard  —  FIPS  PUB  119),  and  ANSI  approval  of  the 
Ada  9X  standard  is  expected  in  1994,  as  shown  in  Figure  9-1 .  Current  plans  call  for  DoD  and  NIST 
adoption  of  the  approved  ANSI  standard  for  Ada  9X.  Although  ANSI  approval  of  the  Ada  9X  standard  is 
planned  for  late  1994,  initial  implementations  may  be  available  sooner,  perhaps  even  before  Ada  9X 
compiler  validation  is  available.  ISO  approval  of  the  ANSI  standard  may  take  at  least  two  years  after  ANSI 
approval,  due  to  voting  procedures. 


9.2.  The  Ada  9X  Project 

The  Ada  9X  Project  is  the  effort  to  revise  the  standard  for  the  Ada  programming  language, 
obtain  adoption  of  the  revised  standard,  and  effect  a  smooth  transition  from  Ada  83  to  Ada  9X. 

The  goal  of  the  Ada  9X  Project  has  been  to  revise  ANSi/MIL-STD-1815A  to  reflect  current  essential 
requirements  while  minimizing  negative  impacts  and  maximizing  positive  impacts  on  the  Ada  community. 
On  the  other  hand,  as  the  design  of  the  Ada  language  is  based  on  late  1970s  programming  language 
technologies,  it  is  important  to  make  enhancements  to  meet  user  needs  in  the  many  diverse  applications 
that  Ada  successfully  supports  today. 

The  Ada  9X  Project  has  tried  to  balance  the  necessary  changes  for  Ada’s  continued  growth  in  the  1990s 
with  the  need  for  stability  in  terms  of  preserving  the  irrtegrity  of  existing  Ada  software  and  toois.  The 
project  has  tried  in  a  number  of  ways  to  balance  these  concerns,  as  demonstrated  in  the  Ada  9X  Project 
Plan  [11]  and  the  Ada  9X  Transition  Plan  [12]. 


^See  Apperrdix  B.3  for  contact  information. 
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Figure  9-1 :  Projected  Ada  9X  Schedule 

The  Ada  9X  Project  Office  has  had  wide  participation,  both  within  and  outside  DoD,  including  the: 

•  Requirements  Team  (collated  more  than  750  revision  requests  from  the  public  and  more  than 
800  language  issues  and  questions  since  Ada  83;  performed  tradeoff  studies  of  proposed 
changes;  developed  requirements  for  Ada  9X  [71]) 

•  Mapping/Revision  Team  (mapped  requirements  into  proposed  language  solutions) 

•  Distinguished  Reviewers  (from  industry,  government,  academia,  tool  vendors,  system  producers) 

•  ACVC  Team 

•  ACVC  Reviewers 

•  User/Implementer  Teams  (prototyped  usage  of  proposed  language  changes  in  compilers  and 
multiple  applications  areas) 

•  Language  Precision  Team  (ensured  that  no  ambiguities  were  being  introduced  by  changes  to  the 
language) 

The  Ada  9X  Transition  Plan  [12]  describes  activities  that  the  Ada  9X  Project  will  be  undertaking  to  assist 
in  the  transition  from  Ada  83  to  Ada  9X.  Three  goals  have  driven  this  transition  planning: 

1 .  Meet  user  needs  as  soon  as  possible. 

2.  Promote  the  development  of  high  quality  Ada  9X  products. 

3.  Recognize  that  there  are  diverse  customer  bases  within  the  Ada  community  and  that  dif¬ 
ferent  vendors  may  support  one  or  more  of  these  customer  bases. 

The  effect  on  managers,  programmers,  vendors,  educators,  authors,  and  various  application  domains  wili 
be  considered  in  this  transition  planning. 
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9.3.  Transitioning  to  Ada  9X 

Ada  9X  will  not  introduce  radical  changes  to  Ada  83.  Rather,  enhancements  are  being 
planned  to  minimize  incompatibilities,  as  Ada  9X  is  planned  to  maximize  upward  compatibility 
with  Ada  83. 

The  revisions  leading  to  Ada  9X  are  intended  to  include  only  those  changes  that  improve  the  usability  of 
the  language  while  minimizing  the  disruptive  effects  of  changing  the  standard.  This  is  critical,  as  a 
significant  infrastructure  and  investment  exist  in  Ada  83;  its  programs,  programmers,  training  material, 
tools,  and  experience  base.  Ada  9X  is  planned  to  be  upwardly  compatible  with  Ada  83  (i.e.,  most  Ada  83 
programs  will  compile  and  run  under  Ada  9X  compilers). 

Three  major  enhancements  are  planned  in  Ada  9X  [215]; 

1 .  improvements  in  object-oriented  programming 

2.  programming  in  the  large 

3.  real-time  and  parallel  programming  capabilhies 

It  took  several  years  after  the  release  of  Ada  83  to  achieve  production-quality  compilers  for  numerous 
applications.  The  Ada  9X  Project  is  taking  several  steps  to  hasten  the  availability  of  usable  Ada  9X  tools. 
Among  these  steps  is  a  change  in  the  concept  of  the  Ada  language  standard  in  terms  of  a  core  language 
and  several  annexes,  which  provide  extended  features  for  specific  application  areas.  Thus,  Ada  9X 
compilers  are  anticipated  to  be  available  in  several  phases: 

•  Early-release  compilers  probably  sometime  during  1994  (before  the  Ada  9X  standard  is  ap¬ 
proved). 

•  Application-oriented,  production-quality  compilers,  which  implement  the  core  language  and 
selected  annexes,  within  two  years  after  the  standard  is  approved  (approximately  1996). 

•  Full,  production-quality  Ada  9X  compilers,  implementing  the  full  Ada  9X  standard  (core  and  an¬ 
nexes),  within  three  years  after  the  standard  is  approved  (approximately  1997). 

However,  great  care  is  being  taken  to  avoid  sudden  mandates  to  use  Ada  9X  prior  to  having  the  neces¬ 
sary  Ada  9X  infrastructure  well  established  (e.g.,  tools,  training).  More  importantly  to  the  program 
manager,  some  Ada  9X  issues  must  be  addressed  (e.g..  which  Ada  standard  to  apply,  when  to  upgrade 
the  system  to  Ada  9X  or  to  continue  doing  system  upgrades  using  Ada  83  tools  and  language). 

A  subgoal  of  the  Ada  9X  efforts  was  to  maximize  upward  compatibility  from  Ada  83  in  the  addition  of  new 
features  and  capabilities  to  the  Ada  9X  language.  Complete  upward  compatibility  is  not  feasible,  given 
the  scope  of  changes  being  made.  However,  the  number  of  incompatibilities  is  small.^  The  Ada  9X 
Project  Office  will  produce  a  document  describing  what  incompatibilities  exist  and  how  to  write  Ada  83 
software  to  minimize  changes  in  transitioning  to  Ada  9X.  The  Ada  9X  Project  is  also  developing  tools  that 
will  examine  Ada  83  software  to  identify  potential  incompatibilities  and  recommend  appropriate  Ada  9X 
alternatives.  For  example,  software  that  is  written  in  Ada  83  can  be  later  compiled  with  an  Ada  9X 
compiler  after  the  Ada  9X  tool  has  been  used  to  identify  any  incompatibilities.  Verrdors  can  expect  a 
gradual  phase-in  and  a  more  stable  test  suite  concentrating  on  language  usage.  Users  can  also  expect  a 
gradual  phase-in,  with  the  norm  being  program  managers  making  the  decision  on  when  to  shift  to  Ada  9X. 


®®The  proposed  Ada  9X  revision  is  upwardly  compatible  for  most  existing  Ada  83  applicatiorts.  Most  incompatibilities  are 
restrictad  to  combinations  of  features  that  are  rarely  used  in  practice,  (A  thorough  analysis  of  the  upward  incompatibilities  is 
provided  in  [S].) 
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The  Ada  9X  Project  is  also  taking  several  steps  to  hasten  the  availability  of  usable  Ada  9X  tools.  For 
example,  one  such  effort  is  the  GNU  Ada  9X  compiler,  which  will  be  available  from  the  Free  Software 
Foundation  (meaning  that  free  source  code  for  an  Ada  9X  compiler  will  be  widely  available).^^ 

Under  the  proposed  policies,  new  projects  will  have  the  choice  of  using  Ada  83  or  Ada  9X  until  the  final 
Ada  9X  validation  suite  (ACVC  2.1)  is  officially  released  (approximately  24  months  after  ANSI  approval) 
[12].  The  new  projects,  which  are  scheduled  for  completion  before  ACVC  2.1  is  released  and  that  have 
software  end-products  with  a  life  expectancy  of  three  years  or  more,  must  use  Ada  83  (i.e.,  ACVC  2.0  will 
not  be  used  for  project  registration^^  of  compilers  for  long-lived  projects).  Issues  regarding  compiler 
performance  and  quality  wilt  have  to  be  evaluated  as  part  of  the  compiler  evaluation  and  selection 
process. 

As  with  today’s  policies,  existing  non-Ada  projects  will  transition  to  Ada  if  a  major  project  upgrade  is 
planned.  Existing  Ada  83  projects  can  transition  to  Ada  9X  if  it  is  determined  that  Ada  9X  brings  neces¬ 
sary  or  desirable  functionality  to  the  project.  For  Ada  83  projects  using  a  project  compiler,  the  "major 
project  upgrade*  rule  does  not  apply  (i.e.,  Ada  83  projects  using  a  validated  Ada  83  project  coirpiler  6o 
not  have  to  upgrade  to  Ada  9X). 

However,  if  It  can  be  determined  that  a  program  will  make  future  use  of  Ada  9X  enhancements,  the 
program  may  choose  to  design/oode  in  Ada  83  to  be  as  compatible  as  possible  with  Ada  9X  (i.e.,  consider 
life-cycle  upgrades  ahead  of  time).^^  This  might  be  a  wise  investment  by  the  program  office  now,  even 
though  the  resulting  impact  will  not  be  felt  until  the  future.  This  is  very  similar  to  dealing  with  any  other 
preplanned  product  improvement  (P^l)  opportunities  —  planning  ahead  for  a  technology  upgrade  during 
development. 

The  transition  to  Ada  9X  will  not  be  totally  transparent;  It  will  require  attention  to  some  of  the  transition 
lessons  learned  from  Ada  83  —  improving  people,  tools  and  tasks  to  deal  with  Ada  9X  and  its  improved 
capabilities  —  and  a  wise  program  manager  will  anticipate  this. 


“1^  Ada  ex  Project  Office,  in  coordination  with  the  AJPO,  OARPA,  and  the  DoD’e  Corporate  Information  Management  (CIM) 
initiative,  is  sponsoring  the  development  of  GNU  Ada  9X.  New  York  University  is  working  dosely  with  the  Free  Software  Foundation 
(FSF)  to  develop  a  GNU  Ada  9X  compiler  written  in  Ada.  Release  is  planned  prior  to  Ada  9X  approval  to  allow  users  the  opportunity 
to  have  early  hands-on  experience  with  some  of  the  Ada  9X  enhancements.  However,  this  compiler  may  not  implement  all  of  the 
proposed  Ada  9X  standard,  including  the  core  language  and  anrtexes.  Compilers  will  he  targeted  to  personal  computers,  the  Sun 
SPARC  workstation,  and  the  Sun  multiprooessor.  Additionally,  implementalionB  of  bindings  to  the  X  Window  System,  POSIX,  and 
Mach  are  also  planned. 

*°A  project  compiler  is  a  validated  Ada  compiler  that  is  selected  by  a  specific  project  and  baselined  in  accordance  with  applicable 
configuration  management  practices.  A  project  compiler  may  be  used  for  the  life  of  the  project  Project  registration  of  the  compiler  is 
recommended  by  (3.  Appendix  F].  Project  registration  is  aocomplishod  by  having  the  project  manager  inform  the  AJPO  that  the 
project  will  be  using  a  particular  compiler  beyond  its  certificate  life. 

'^A  set  of  twelve  coding  guidelines  for  Ada  83  programmers  has  been  developed  which  ensures  that  Ada  83  code  will  not 
encounter  the  few  presently  existing  incompatibilities,  once  this  code  gets  transitioned  into  Ada  9X  environments.  These  guidelines 
are  planned  to  be  published  in  a  paper  by  Dr.  Erhard  Ploedereder,  Chairman  of  the  Ada  9X  Distinguished  Reviewers,  in  Ada  Letters 
These  guidelines  are  also  available  on  the  Ada  9X  electronic  bulletin  board. 
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9.4.  Ada  9X  Validation 


Ada  validation  policies  are  intended  to  support  the  transition  to  Ada  9X. 

The  Ada  Compiler  Validation  Capability  (ACVC)  is  the  suite  for  testing  conformance  to  the  language 
standard.  The  two  versions  of  the  ACVC  planned  for  Ada  9X  are  shown  in  Figure  9-1 .  The  first  version, 
ACVC  2.0,  is  planned  to  be  officially  released  approximately  three  months  after  ANSI  approval  of  Ada  9X. 

All  Ada  validation  certificates  issued  for  validations  completed  with  ACVC  Version  1.10  expired  on 
December  1 , 1990.  ACVC  Version  1 .1 1  is  currently  the  official  validation  test  suite  for  Ada  83  and  will 
remain  in  effect  until  after  ANSI  adoption  of  Ada  9X.  ACVC  Version  1 .1 1  may  have  test  programs 
wKhdrawn  but  there  will  be  no  additions,  modifications,  or  re-issuance  of  an  ACVC  version  that  measures 
conformity  with  the  standard  until  Ada  9X.  The  certificates  associated  with  validations  completed  with 
ACVC  Version  1.11  will  remain  current  until  release  of  the  full  Ada  9X  ACVC.  This  extended  life  for 
ACVC  1.11  means  that  there  will  be  an  overlap  period  between  ACVC  1 .1 1  (for  ANSI/MIL-STD 181 5A 
validations)  and  ACVC  2.0  (for  Ada  9X  validations)  allowing  users  the  choice  of  Ada  83  or  Ada  9X  until 
ACVC  2.1  (full  Ada  9X  testing)  is  required. 

The  first  release  of  the  ACVC  for  Ada  9X  (ACVC  2.0)  will  consist  of  most  of  the  Ada  9X  tests  and  will  be 
modularly  constructed^  so  that  vendors  may  choose  the  set  of  tests  that  best  satisfies  their  customer 
base.  The  number  of  modules  will  be  kept  small,  and  vendors  must  pass  complete  modules  to  get  credit 
for  passing  a  particular  validation  module.  All  vendors  must  pass  a  core  set  of  ACVC  modules  to  obtain 
compiler  validation. 

The  next  ACVC  release  (ACVC  2.1)  will  be  similar  to  ACVC  2.0  but  will  be  more  complete,  providing 
coverage  of  the  core  Ada  9X  languages  and  the  annexes.  This  approach  will  aid  in  avoiding  some  of  the 
delays  that  had  been  encountered  waiting  for  complete,  validated  Ada  83  compilers  and  will  allow  quality 
products  to  reach  users  with  the  enhanced  features  that  they  need  for  their  application  domains.  Thus, 
early  vendor  implementations  can  be  tailored  to  user  needs.  For  example,  if  a  real-time  oriented  compiler 
Is  available  and  validated  under  ACVC  2.0,  real-time  users  will  not  initially  be  penalized  waiting  for  a  full 
ACVC  2.1  compliant  compiler  that  implements  all  Ada  9X  features.  Some  compiler  vendors  may  decide 
to  skip  ACVC  2.0  and  put  all  their  resources  into  validating  Ada  9X  compilers  with  the  more  complete 
ACVC  2.1. 


®Thi6  reflects  the  mtxfcjiarity  of  the  Ada  9X  language.  As  with  Ada  83,  there  is  a  core  language,  which  must  be  implemented  in  its 
entirety.  In  Ada  9X,  several  annexes  are  defined,  which  provide  extended  features  for  specific  application  areas.  These  annexes 
provide  standard  definitions  for  application-specific  r^uirements  for:  systems  programming,  real-time  systems,  distributed  systems, 
information  systems,  safety  and  security,  and  numerics.  The  Ada  9X  language  will  be  defined  in  terms  of  the  core  language,  which 
is  mandatory  for  compiler  validation,  and  the  annexes,  which  are,  for  the  most  part,  optional. 
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9.5.  For  More  Information . . . 

Recommended  readings  for  those  seeking  more  information  about  the  topics  addressed  in  this  chapter 
inciude: 

Ada9X 

•  Ada  9X  Project  Plan  [11] 

•  Ada  9X  Requirements  [71  ] 

•  Ada  9X  Transition  Plan  [12] 

•  Ada  9X  Mapping: 

•  Volume  1  —  Mapping  Rationaie  [5] 

•  Voiume  2 —  Mapping  Specification  [6, 7] 
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Appendix  A:  Ada  Information 


A.1 .  Readings 

Recommended  readings  for  those  seeking  fundamental  Ada  information  include: 

•  Ada  Adoption  Handbook:  A  Program  Manager’s  Guide  [this  volume]. 

•  Ada  Adoption  Han<tt)OOk:  Compiler  Evaluation  and  Selection  (226). 

•  Proceedings  of  TRI-Ada  conferences  [108, 97, 38, 99]. 

•  Ada  Language  Reference  Manual [^3]. 

•  Beginning  programming  texts  using  Ada,  such  as  [102, 199],  or  other  texts  that  introduce  Ada  to 
readers  with  prior  programming  experience,  such  as  [59],  [36],  [206],  or  [43, 171]. 

Collections  of  information  about  Ada  include  the  ACM's  Resources  in  Ada  [1 1 1];  Ada:  Sources  and 
Resources  [180];  and  various  bibliographies  available  through  the  Ada  Information  Clearirtghouse  (see 
below). 

Ada  9X  publications  include: 

•  Ada  9X  Requirements  [71]. 

•  Ada  9X  Transition  Plan  [1 2]. 

•  Ada  9X  Mapping: 

•  Volume  1  —  Mapping  Rationale  [5] 

•  Volume  2 —  Mapping  Specification  [6, 7] 


A.2.  Resources 

A  primary  source  for  Ada-related  information  is  the  Ada  Information  Clearinghouse  (AdalC).  The  AdalC 
supports  both  the  AJPO  and  the  Ada  9X  Project  Office  by  distributing  Ada-related  infonnation  (see  Sec¬ 
tion  B.3  for  more  information). 

Ada  information  is  also  available  through  various  electronic  sources.  This  information  is  often  more  up  to 
date  and  more  readily  available  than  traditional  printed  materials.  Various  Ada-related  electronic  bulletin 
board  services  (BBS)  are  available: 

•  Ada  Information  Clearinghouse  —  (800)  232-9925 

•  Ada  9X  Electronic  Bulletin  Board  —  (800)  ADA-9X25 

A  source  of  much  Ada  information,  including  information  from  the  Ada  Information  Clearinghouse  and  the 
Ada  9X  Project  Office,  is  an  Internet-accessible  computer  (ajpo.sei.cmu.edu,  128.237.2.253).  This 
machine  is  sponsored  by  the  Ada  Joint  Program  Office  (AJPO)  and  is  accessible  to  anyone  who  has  ftp 
(file  transfer  protocol)  access  to  the  AJPO  machine.  On  the  AJPO  machine,  the  directories  contain  Ada 
9X  documents  and  the  contents  of  the  Ada  Information  Clearinghouse  electronic  bulletin  board  service 
(BBS).  For  example,  an  up-to-date  list  of  validated  Ada  compilers  is  available  from  the  AdalC  through  its 
electronic  bulletin  board  services  (BBS,  or  from  this  Internet-accessible  computer. 
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The  following  sample  session  illustrates  an  Internet  user  accessing  the  AJPO  machine.  Those  on  other 
networks  will  need  to  consult  their  system  managers  to  determine  whether  they  have  ftp  access  to  these 
Internet  databases.^ 

In  this  script,  which  retrieves  the  latest  listing  of  validated  compilers,  lines  on  which  the  user  enters 
information  are  preceded  with  asterisks.  The  commands  and  information  that  the  user  types  are  shown  in 
italics.  It  should  be  noted  that  "cd"  Is  the  Unix  “change  directory*  command.  At  any  directory,  the  user 
may  type  "Is"  for  a  listing  of  the  files  or  directory  entries  that  are  contair)ed  in  the  current  directory. 

To  retrieve  the  latest  validated  compiler  list: 

1 .  Connect  to  the  AJPQ  machine. 

*  ftp  ajpo.sei.cmu.edu 

CoDMctad  to  ajpo.aol.oau.odu. 

220  ajpe.sol.au.odu  FTP  aorvor  (SIZ  Voralon  4.3  Frl  Jun  19  13:27:55  tST  1992)  roady. 


2.  Login  to  the  AJPO  machine. 

*  Naaa  (ajpo.aol.eau.odu: ) :  anonymous 

*  Paaavexd  (ajpo.aol.oau.odu:anonyMua) :  your nama hero 
331  Guaat  lo«in  ok,  aond  Idant  aa  paaavord. 

230  Guoat  login  ok,  aoooaa  roatrlotlona  apply. 


3.  Move  to  the  public  directory  containing  Ada  information,  note:  ftp>  is  the  prompt  from  the  AJPO 
machine. 

•  ftp>  cdpubiic/ada-in/o 

250  CUD  nnaaiarid  auoooaafol. 

•  ftp>  Is 

200  PORT  rnaoantl  atieooaaXul. 

ISO  OpoBlng  data  eonnaetlon  for  /bin/la  (129.237. 1.26, 3917)  (0  bytaa) . 

At  this  point,  the  listing  of  all  the  files  in  the  ada-info  directory  will  appear.  This  listing  is  quite  long,  and 
may  scroll  off  your  screen.  This  example  shows  only  the  last  few  lines  of  the  listing: 

▼al -ooap . blp . OlOot 92 
▼al -doo .  blp .  1 9llay  92 
val-nov.blp. OlOooPO 
▼al -proe . hip . 01*ug90 
▼alfaelX  .hip.  05l>ae91 
▼ar-doeu .  hip.  29,7U192 
vlthdnm.hlp.  06ita>g91 
x-auxvoy . hip . 01Vov91 
226  Tranafar  eo^plata. 

16S1  bytaa  raoaivad  in  2.73  aaoonda  (0.67  lOsytaa/a) 


4.  Determine  the  correct  filename  to  retrieve  the  current  list  of  validated  compilers.  The  filename  begins 
with  vai*comp.hlp.  and  ends  with  the  as-of  date  of  the  file.  In  this  example,  we  are  retrieving  the  file 
val-comp.hlp.Ol  Oct92. 


best  resource  on  the  various  networks  and  how  to  navigate  among  them  is  given  in  The  Ada  Sotiware  Repository  and  the 
Defense  Data  Network  |61  ]. 
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5.  Retrieve  the  current  list  of  validated  compilers,  using  the  correct  filename  (including  the  as-of  date  at 
the  end  of  the  filename). 

*  ftp>  mget  val<ompMp.01OelS2 

*  val-oe«p.hlp.010et92?  y 
200  VOKt  Poland  okay. 

ISO  Opontng  data  oonaaetlon  for  val-ooap.hlp.010ot92  (128 .237.1.26, 3919) (15417c  bytoa) . 

226  Tranafor  ooo^loto. 

local;  val-eoap.hlp. 010ot92  roaoto:  val-aoap.hlp.010ot92 
161S70  bytoa  rocolvod  In  0.8S  aaoooda  (1.9*402  lOytaa/a) 

6.  Logoff  the  AJPO  machine. 

*  ftp>  quit 
gult 

221  Coodbya. 

7.  The  file  containing  the  list  of  validated  compilers  will  appear  in  your  current  directory.  This  file  is 
currently  named  valcomp.hlp.01Oct92;  the  date  at  the  end  of  the  file  name  will  change  as  the  file  is 
updated  by  the  AdalC. 

iere  are  other  sources  of  useful  Ada  information.  For  example,  Grebyn  Corporation^  has  available  an 
annotated  Ada  reference  manual  that  intersperses  all  the  approved  language  commentaries  in  their 
proper  place  in  the  language  reference  manual. 

Asset  Source  for  Software  Engineering  Technology  (ASSET)  is  a  focal  point  for  software  reuse  and 
provides  reusable  software  componerrts,  based  in  the  ASSET  library,  as  well  as  descriptions  and  kx^a- 
tions  of  components  available  from  other  software  reuse  libraries.  See  Section  B.3  for  additional  infor¬ 
mation  on  ASSET. 


•♦Contact  Grebyn  Corporation,  P.O.  Box  497,  Vienna,  VA  22183-0497,  (703)  281-2194,  E-mail:  products<g>grebyn  com,  for  further 
information. 
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Appendix  B:  Ada  Working  Groups  and  Resources 

Many  groups  are  involved  in  Ada  technology  activities.  In  the  following  sections,  details  of  various  groups 
are  discussed,  including: 

•  professional  organizations 

•  standards  organizations 

•  U.S.  govemment-sponsored/endorsed  organizations 

•  DoD  Software  Executive  Officials 

Contact  information  is  provided:  where  known,  Defense  Switched  Network  (DSN,  formerly  AUTOVON 
numbers)  and/or  electronic  mail  (E-mail)  addresses  are  also  included. 


B.1 .  Professional  Organizations 

Ada  Joint  Users  Group  (Ada JUG) 

Ada  Joint  (Services)  Users  Group  (AdaJUG)  (formerly  Ada-JOVIAL  Users  Group)  is  a  non-profit  organiza¬ 
tion  whose  purpose  is  to  encourage  a  dialogue  between  Government  and  Industry  concerning  Ada 
issues.  The  AdaJUG  makes  recommendations  to  appropriate  military  services  and  DoD  agencies  regard¬ 
ing  language  policies  and  practices.  The  current  AdaJUG  chair  is: 

Mike  Ryer 
Intermetrics 
733  Concord  Ave. 

Cambridge,  MA  02138 
(617)  661-1840 

B.1 .2.  SIGAda 

The  Association  for  Computing  Machinery  Special  Interest  Group  on  Ada  is  a  scientific  association 
focused  on  the  Ada  language.  Ada  Letters  is  the  SIGAda  bimonthly  publication.  The  current  SIGAda 
chair  is: 

Mark  Gerhardt 

ESL  Inc.,  MS  M507 

495  Java  Drive 

Sunnyvale,  CA  94088-3510 

(408)  752-2459  or  (408)  738-2888  (Switchboard) 

Email:  gerhardt@ajpo.sei.cmu.edu 

SIGAda  sponsors  a  number  of  working  groups.  These  and  current  points  of  contact  are  normally  listed  in 
Ada  Letters.^  The  following  are  the  current  SIGAda  working  groups: 

•  AlWG:  Artificial  Intelligence  Working  Group 

•  ARTEWG:  Ada  Runtime  Environment  Working  Group 

•  CAISWG;  CAIS  Working  Group 

•  CAUWG:  Commercial  Ada  Users  Working  Group 


“To  obtain  information  about  membership  or  Ada  Letters,  contact  ACM,  1515  Broadway,  New  York,  NY  10036-9998, 

(212)  869-7440,  or  e-mail  acmhelpt^acmvm.bitnet  Single  copies  of  Ada  Letters  may  be  purchased  from  the  ACM  Order  Dept,  at 
(800)  342-6626  or  (410)  528-4261 . 
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•  EDWG;  Educational  Products  Working  Group 

•  NUMWG:  Numerics  Working  Group 

•  OBJWG:  Obiect-Oriented  Working  Group 

•  PIWG;  Performance  Issues  Working  Group 

•  REUSEWG:  Reuse  Working  Group 

•  SDSAWG:  Software  Development  Standards  and  Ada  Working  Group 

•  SSTOWG;  Secondary  Standards  Working  Group 

B.1.3.  Other  Professional  Organizations  (World-Wide) 

While  SIGAda  and  AdaJUG  are  the  predominant  U.S.  professional  Ada  organizations,  similar  organiza¬ 
tions  exist  in  Europe  and  around  the  world.  In  addition  to  Ada-Europe,  there  are  also  Ada  groups  as¬ 
sociated  with  the  Commission  of  the  European  Communities  and  the  European  Space  Agency.  Ada 
organizations  also  exist  in  Australia,  Canada,  Denmark,  France.  Gennany,  Greece,  Ireland,  the  Nether¬ 
lands,  Norway,  Scotland,  Spain,  Sweden,  Switzerland,  and  the  United  Kingdom.  Contact  information  for 
these  organizations  can  be  found  in  Ada  Letters. 


B.2.  Standards  Organizations 

ISO/IEC  JTC1/SC22  WG9  Ada 

•  Purpose:  Standardization  of  the  Ada  programming  language  is  the  responsibility  of  a  working 
group  under  the  International  Organization  for  Standardization  and  the  International  Electro- 
Technical  Commission  known  as  ISO/IEC  JTC1/SC22  WG9.  Ada  was  initially  developed  as  a 
military  standard  (MIL-STO-1815A)  and  became  an  American  National  Standards  Institute 
(ANSI)  standard  (ANSI/MIL-STD-1815A,  1983)  through  the  canvass  process.  It  is  also  a  Federal 
Information  Processing  Standard  (FIPS  119. 1985)  of  the  National  Institute  of  Standards  and 
Technology  (NIST)  as  an  endorsement  of  the  Ada  standard  as  created  by  others.  All  the  ver¬ 
sions  of  the  standard  are  identical  to  ISO  8652:1987. 

Membership  in  WG9  is  held  by  national  standards  organizations  rather  than  individuals.  About 
twenty  countries  are  actively  participating  in  the  work.  In  the  case  of  the  United  States,  the 
national  body  is  ANSI,  which  delegates  the  work  to  a  group  called  the  U.S.  TAG  (Technical 
Advisory  Group)  for  WG9.  The  TAG  is  responsible  for  developing  national  positions  and  naming 
members  of  the  delegations  to  attend  WG9  meetings.  The  TAG  is  co-chaired  by  Christine  Ander¬ 
son  (program  manager  for  Ada9X)  and  John  Soiomond  (director  of  the  Ada  Joint  Program  Of¬ 
fice). 

WG9  meets  at  least  twice  yearly  and  is  led  by  its  convener,  Robert  Mathis  (USA),  a  former 
director  of  the  Ada  Joint  Program  Office.  Most  of  the  work  of  WG9  in  drafting  standards  is 
performed  in  smaller  bodies  called  "rapporteur  groups.”  In  principle,  every  proposal  for  a  stan¬ 
dard  is  formulated  as  a  "work  Hem."  New  work  Hems  are  approved  at  the  JTCl  level  and  even¬ 
tually  assigned  to  a  rapporteur  group.  The  standards  drafted  by  the  rapporteur  groups  work  their 
way  up  through  the  ISO  hierarchical  balloting  process  wHh  successive  designations  as  Com- 
mHtee  Draft  (CD),  Draft  International  Standard  (DIS)  and,  finally.  International  Standard  (IS). 

Currently  there  are  eight  rapporteur  groups  wHhin  WG9.  AHhough  the  work  of  these  groups  is 
generally  focused  on  the  current  Ada  standard,  all  of  them  are  also  actively  participating  in  the 
development  of  the  proposal  for  Ada  9X: 

1.  Ada  Rapporteur  Group  (ARG) 

2.  Character  Rapporteur  Group  (CRG) 

3.  Information  Systems  Rapporteur  Group  (IRG) 
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4.  Numerics  Rapporteur  Group  (NRG) 

5.  Real-time  Rapporteur  Group  (RRG) 

6.  SQL  Rapporteur  Group  (SRG) 

7.  Uniformity  Rapporteur  Group  (URG) 

8.  Ada  9X  Rapporteur  Group  (XRG) 

Not  all  standardization  related  to  Ada  occurs  in  WG9.  Sometimes  bindings  from  standards  to 
particular  languages  are  performed  by  the  language  committee,  and  sometimes  they  are  per¬ 
formed  by  the  committee  that  created  the  standard.  For  example,  the  Ada  binding  to  POSIX  is 
under  ISO/IEC  JTC1/SC22  WG15  and  IEEE  PI 003.5. 

For  further  information,  contact: 

Dr.  Robert  Mathis,  Convener 
ISO/IEC  JTC1/SC22  WG9  Ada 
Suite  1815 
4719  Reed  Road 
Columbus,  Ohio  43220 
(614)  538-9232 

Email:  mathis@ajpo.cmu.sei.edu 


POSIX  /Ada  working  group: 

•  Purpose:  Develop  an  Ada  binding^  to  the  application  programming  interfaces  (API)  defined  in 
the  POSIX  operating  system  specification  ISO/IEC  9945-1 : 1990  (IEEE  Std  1003.1-1990). 

IEEE  PI  003.5  is  a  single  committee  that  has  been  working  on  two  projects: 

1 .  Ada  binding  to  POSIX:  The  PI 003.5  project  ot^ective  has  been  to  provide  Ada 
Language  interfaces  to  the  PI  003.1  POSIX  operating  system  specification.  This 
work  has  resulted  in  the  adoption  of  IEEE  Std  1003.5-1992,  which  defines  a  binding 
to  IEEE  Std  1003.1. 

2.  Ada  binding  to  the  IEEE  Std  1003.4  POSIX  real-time  extensions:  The  Pi  003.20 
project  objective  is  to  define  an  Ada  language  binding  to  the  P1003.4/4a  real-time 
POSIX  extensions. 

For  further  information,  contact: 

James  P.  Longers 
Paramax  Systems  Corporation 
70  E.  Swedesford  Rd. 

P.O.  Box  517 
Paoli,  PA  19301  U.S.A. 
email:  longers@prc.unisys.com 
(215)  648-2670 


In  addition,  an  electronic  mailing  list  has  been  established  for  those  interested  in  POSIX-Ada 
binding.  For  more  information,  or  to  subscribe  to  the  list,  send  computer  mail  to  posix-ada- 
request@verdix.com. 


‘^The  POSIX  Ada  Language  Interface  standard  is  contained  in  IEEE  Sid  P1003.5. 
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B.3.  U.S.  Government  Sponsored/Endorsed  Organizations 

AJPO:  Ada  Joint  Program  Office 

•  Purpose;  Oversees  the  total  direction  of  the  Ada  program.  The  AJPO  reports  to  the  Deputy 
Undersecretary  of  Defense  for  Research  and  Advarwed  Technology  (DUSDR&AT).  For  further 
information,  contact: 

Dr.  John  Solomond,  Director 

Ada  Joint  Program  Office 

The  Pentagon,  Room  3E118 

Washington,  D.C.  20301-3081 

(703)  614-0208 

Fax:  (703)  685-7019 

Email:  solomond@ajpo.sei.cmu.edu 

Ada  9X  Project  Office: 

•  Purpose:  Responsible  for  revising  the  Ada  83  starKlard.  (See  Chapter  9  for  more  information  on 
the  Ada  9X  Project.)  For  further  information,  contact: 

Christine  Anderson 
Ada  9X  Project  Office 
PLyVTET 

Kirtland  AFB  NM  87117-6008 
(505)846-0817 

Fax:  (505)  846-2290  -  Attn:  Chris  Anderson 
Email;  andersonc@plk.af.mil 

Ada  Federal  Advisory  Board: 

•  Purpose:  A  federal  advisory  committee,  composed  of  compiler  developers,  language  designers, 
embedded  system  users,  educators,  and  government  personnel  that  provides  the  Director  of  the 
AJPO  'Vrith  a  balanced  source  of  advice  and  information  regarding  the  technical  and  policy 
aspects  of  the  Ada  Program  [4]."  For  further  information,  contact: 

Dr.  John  Solomond,  Director 

Ada  Joint  Program  Office 

The  Pentagon,  Room  3E1 18 

Washington,  D.C.  20301-3081 

(703)  614-0208 

Fax;  (703)  685-7019 

Email:  solomond@ajpo.sei.cmu.edu 

AdalC:  Ada  Information  Clearinghouse 

•  Purpose:  Supports  the  AJPO  by  distributing  Ada-related  information,  including: 

•  policy  statements 

•  lists  of  validated  compilers 

•  classes 

•  conferences 

•  text  books  and  serials  relating  to  Ada 

•  projects  using  Ada 

Also  supports  the  Ada  9X  Project  Office  by  serving  as  the  distribution  point  for  information  re¬ 
lated  to  the  Ada  9X  Project.®^ 


Ada  9X  documents  are  also  available  electronically  on  the  Ada  9X  BBS  at  (800)  Ada-9X25  or  (301 )  459-8939. 
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In  addition  to  publishing  a  free  quarterly  newsletter,  an  electronic  bulletin  board  system  (300 
through  9600  baud,  no  parity,  8  bits,  1  stop  bit)  is  available  at  (703)  614-0215.  This  bulletin 
board  also  provides  access  to  the  AdalC's  Ada  products  and  tools,  Ada  article  abstracts,  and 
Ada  bibliography  databases. 

The  Ada  Information  Clearinghouse  (AdalC)  also  maintains  files  on  the  AJPO  host,  which  are 
available  via  anonymous  FTP  from  the  public  directories  on  the  AJPO  host  computer 
(ajpo.sei.cmu.edu). 

For  further  information,  contact; 

Ada  Information  Clearinghouse 
c/o  IIT  Research  Institute  (IITRI) 

4600  Forbes  Blvd. 

Unham  MD  20706-4312 
(800)  Ada-ICII  or  (703)  685-1477 
Fax:  (703)  685-7019 

Email:  adainfo@alpo.sei.cmu.edu;  CompuServe  70312,3303 

IIT  Research  Institute  operates  the  AdalC  for  the  Ada  Joint  Program  Office. 

AVO:  Ada  Validation  Organization 

•  Purpose:  The  AVO  is  directly  responsible  to  the  AJPO.  The  AVO  coordinates  and  administers 
cornpiler  validation  policy  and  procedures.  For  further  information,  contact: 

Ada  Validation  Organization 
Institute  for  Defense  Analyses 
ATTN:  Audrey  Hook 
1801  Beauregard  Street 
Alexandria,  Virginia  2231 1 
(703)  845-6639 
FAX:  (703)  845-6848 
Email:  hook@ida.org 

ACVC  Review  Team:  Ada  Compiler  Validation  Capability  Review  Team 

•  Purpose:  The  ACVC  Review  Team  provides  expert  technical  review  for  the  Ada  Compiler 
Validation  Capability.  For  further  information,  contact; 

Or.  Nelson  Weiderman 
127  Schooner  Drive 
Wakefield,  Rl  02879 
(401)  783-6863 
Email:  nhw@sei.cmu.edu 
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AMO:  ACVC  Maintenance  Organization 

•  Purpose:  Responsible  for  the  development,  maintenance,  and  support  of  the  Ada  Validation 
Suite  (AVS),  which  includes  the  ACVC  and  the  ACEC.  Additionally,  the  AMO  supports  Ada 
language  maintenance  activities.  For  further  information,  contact: 

Steve  Wiison 
ASC/SCEL 

Wright-Patterson  AFB,  Ohio  45433-6503 
(513)  255-4472 
Fax:  (513)  255-4585 
Emaii:  wiisons@adawc.wpafb.af.mil 


Ada-JOVIAL  Newsletter:  The  Standard  Languages  and  Environments  Division,  which  operates 
the  AMO  and  the  Department  of  Defense  Ada  Validation  Facility  at  Wright  Patterson  AFB,  Ohio, 
also  publishes  the  High  Order  Language  Control  Facility  Ada-JOVIAL  Newsletter.  For  further 
information  on  the  Ada-JOVIAL  Newsletter,  contact: 

Dale  Lange 

Standard  Languages  and  Environments  Division 
ASC/SCEL 

Wright-Patterson  AFB,  OH  45433-6503 

Tel:  (513)  255-4472 

E-mail:  langed@adawc.wpafb.af.mil 

ASEET:  Ada  Software  Engineering  Education  and  Training  Team 

•  Purpose:  The  Ada  Software  Engineering  Education  and  Training  (ASEET)  Team  is  composed 
of  representatives  from  the  Army,  Air  Force,  Navy,  Marine  Corps,  other  DoD  agencies,  and 
academia.  The  team  conducts  workshops  arxl  symposia  for  Ada  educators  within  DoD  and 
academia  and  coordinates  the  activities  of  DoD  organizations  engaged  in  meeting  the  Ada 
education  and  training  needs. 

An  ASEET  resource  library  of  educational  materials,  the  ASEET  Material  Library  (AML),  is  lo¬ 
cated  at  the  Ada  Joint  Program  Office.  This  material  is  not  copyrighted  and  can  be  obtained  by 
DoD  personnel  and  copied  at  cost  by  non-DoD  personnel. 

For  further  information,  contact: 

Capt.  David  A.  Cook 

Dept,  of  Computer  Science,  DFCS 

US  Air  Force  Academy,  CO  80840 

(719)  472-3590 

DSN  259-3131 

E-mail:  dcook@ajpo.sei.cmu.edu 

Ada  Software  Engineering  Education  and  Training  Team 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria,  VA  2231 1 

Attn:  Resource  Staff  Member 

(703)  845-6626 


AVF;  Ada  Validation  Facility 

•  Purpose:  Responsible  for  validation  of  Ada  compilers  (giving  priority  to  OoD  targeted  compilers) 
and  registration  of  derived  compilers.^  Ada  Validation  Facilities  currently  exist  in  the  US  (2),  the 
UK,  France,  and  West  Gennany.  For  further  infomnation,  contact  one  of  the  Ada  Validation 
Facility  Managers: 

Captain  Russ  Hilmandolar 

Ada  Validation  Facility 

Language  Control  Facility  ASC/SCEL 

Bldg.  676 /Rm.  135 

Wright-Patterson  AFB,  OH  45433-6503 

Tel:  (513)  255-4472 

Fax:  (513)  255-4585 

E-mail:  hilmanr1<@adawc.wpafb.af.mil 

Fabrice  Gamier  de  Labareyre  or  Alphonse  Philippe 
AFNOR 

Tour  Europe,  Cedex  7 
F-92049  Paris  La  Defence 
FRANCE 

Tel:  +33-1-42-91-5960 
Telefax: +33-1-42-91-5911 

Jon  Leigh  or  Dave  Bamber 
National  Computing  Centre  Lim'tted 
Oxford  Road 
Manchester  Ml  7ED 
ENGLAND 

Tel:  +44  (61)  228  6333 
FAX:  444  (61)  228-2579 

Dr.  William  Dashiell 

National  Institute  for  Standards  and  Technology 

National  Computer  Systems  Laboratory 

Bldg.  255/Room  /V266 

Gaithersburg,  MD  20899 

Tel:  (301)  975-2490 

Fax:  (301)  590-0932 

Michael  Tonndorf 
lABG,  Dept  ITE 
Einsteinstrasse  20 
W-8021  Ottobrunn 
GERMANY 

Tel:  +49-89-6088-2477 


‘‘Derived  compilers  are  defined  on  page  54. 
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For  further  information  on  the  AVFs  or  validation  policies  and  procedures,  contact: 


Ada  Validation  Organization 
Institute  for  Defense  Analyses 
Attn:  Audrey  Hook 
1801  North  Beauregard  Street 
Alexandria,  VA  22311 
Tel:  (703)  845-6639 
FAX:  (703)  845-6848 
Email:  hook@ida.org 

Software  Technology  for  Adaptable,  Reliable  Systems  (STARS) 

•  Purpose:  STARS  is  a  technology  development,  integration,  and  transKion  program  to 
demonstrate  a  process-driven,  domain-specific,  reuse-based  approach  to  software  engineering 
(also  known  as  megaprogranming)  that  is  supported  by  appropriate  tools  and  software  engineer¬ 
ing  environment  (SEE)  technology. 

The  goal  of  the  STARS  Program  is  to  increase  software  productivity,  reliability,  and  quality  by 
synergistically  integrating  support  for  modem  software  development  processes  and  modem 
reuse  concepts  into  state-of-the-art  software  engineering  environment  (SEE)  technology.  To 
meet  that  goal,  STARS  has  set  a  number  of  objectives  for  the  1992-94  time  frame: 

•  Software  Reuse:  Establish  the  basis  for  a  paradigm  shift  to  reuse-based  software 
development. 

•  Software  Process:  Establish  capabilities  for  process  defInKion  and  management,  and 
for  tailoring  processes  to  the  needs  of  the  application. 

•  Environments:  Establish  adaptable,  commerdaliy  viable  SEE  solutions  that  are  built 
upon  open  architecture  industry  standards,  leverage  commercial  products,  and  include 
automated  support  for  process  management  and  software  reuse. 

•  Transitlon/Demonstration/Valldatlon:  Demonstrate  that  the  STARS  integrated  reuse, 
process,  and  SEE  solutions  can  be  used  in  actual  practice  to  increase  the  quality  and 
life-cycle  supportability  of  DoD  software  prorAJCts. 

STARS  maintains  a  multi-level  technology  transition  affiliates  program  to  provide  an  opportunity 
for  the  DOD  software  community  (including  tool  vendors)  to  participate  in  STARS  technical  ac¬ 
tivities. 

For  further  information,  contact: 

John  Foreman 

Software  Technology  for  Adaptable.  Reliable  Systems 
801  N.  Randolph  Street 
Suite  400 

Arlington,  VA  22203 
(703)  243-8655 

E-mail:  affiliates-desk@stars.rosslyn.unisys.com 


Asset  Source  for  Software  Engineering  Technology  (ASSET) 

•  Purpose:  ASSET  was  established  by  the  Defense  Advanced  Research  Projects  Agency 
(DARPA)  under  its  Software  Technology  for  Adaptable.  Reliable  Systems  (STARS)  Program.®® 
ASSET,  located  in  Morgantown,  West  Virginia,  is  chartered  by  DARPA  to  senre  as  a  focal  point 


^^See  page  102. 
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for  software  reuse  and  to  facilitate  a  national  software  reuse  infrastructure  and  industry.  ASSET 
provides  its  client  base  with  reusable  software  conr^nents  based  in  the  ASSET  library  as  well 
as  descriptions  and  location  of  components  available  from  other  software  reuse  libraries. 

The  ASSET  library  consists  of  a  repository  containing  cataloged  assets,  and  a  bibliography  con¬ 
taining  abstracts  and  other  information  needed  to  locate  the  assets  contained  in  the  repository. 
The  repository  currently  contains  three  collections: 

1.  the  STARS  Foundation  collection: 

2.  the  STARS  Catalog  Products  collection,  which  is  a  set  of  reusable  software  assets 
produced  by  the  STARS  prime  contractors;  and 

3.  newly  developed  STARS  key  assets. 

In  addition  to  cataloged  items  in  the  library,  ASSET  also  has  available  other  information  specific 
to  Ada,  e.g.,  Ada  Language  Reference  Manual,  Ada  Software  Repository  assets,  and  ANNA,  a 
Language  Extension  of  Ada,  as  well  as  other  reusable  software  assets. 

In  addition  to  the  library,  ASSET  provides  other  senrices,  including  the  STARS  bulletin  board  and 
newsgroups  with  STARS-specific  and  USENET  pokings.  The  bulletin  board  may  be  accessed 
by  telnet(ing)  to  source.asset.com  and  entering  STARSBBS  at  the  login  prompt.  No  account  is 
needed. 

ASSET  is  currently  developing  a  National  Software  Reuse  Directory  where  producers,  vendors, 
and  other  reuse  libraries  can  list  selected  reusable  components,  and  where  users  looking  for 
sources  of  reusable  components  will  be  able  to  view  what  is  available,  and  where.  This  service 
should  be  available  by  the  end  of  1992. 

ASSET  is  available  to  all  software  developers.  This  includes  commercial,  educational,  and 
private,  as  well  as  government  and  government  contractors.  ASSET  is  available  via  internet  and 
9600  baud  dial  up  modems. 

For  more  information  about  ASSET  and  its  services,  or  to  obtain  a  user  account,  contact: 

ASSET 

2611  Cranberry  Square 
Morgantown,  WV  26505 
(304)  594-3954 
Email:  info@source.asset.com 

Software  Technology  Support  Center  (STSC) 

•  Purpose:  The  STSC  was  established  by  Headquarters,  USAF,  to  senre  as  the  focal  point  for  the 
proactive  management  of  computer  systems  support  tools,  methods,  environments,  and  Ada 
issues  for  Joint  Services  software  activities.  It  is  an  office  of  the  Ogden  Air  Logistics  Center  (Air 
Force  Materiel  Command),  and  is  located  at  Hill  Air  Force  Base,  Utah.  In  addition  to  publishing  a 
free  newsletter,  CrossTalk,  an  electronic  bulletin  board  system  is  available  at  (801)  777-7553 
(DSN  458-7553).  For  further  information,  contact; 

Software  Technology  Support  Center 
Ogden  ALC/TISE 
Building  100,  Bay  G 
Hill  AFB.UT  84056 

(801)  777-8045/7703  (DSN  458-8045/7703) 

Fax:  (801)  777-8069 
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B.4.  DoD  Software  Executive  Officials 

DoD  Instruction  5000.2,  "Defense  Acquisition  Management  Poiicies  and  Procedures,"  Part  6,  Section  D 
fZS]  gives  the  foliowing  guidance: 

Software  Executive  Official.  The  [}oO  Component  Acquisition  Executive  will  designate  a 
senior  level  Software  Executive  official  who  will  monitor,  suji^rt,  and  be  a  focal  point  for  Ada 
usage  and  sound  software  engineering,  development,  and  life-cycle  support  policy  and  prac¬ 
tice. 

This  instruction  replaced  DoD  Directive  3405.2,  "Use  of  Ada  in  Weapon  Systems*  fZS],  which  had  es¬ 
tablished  the  Ada  Executive  Officials  (AEOs).  In  most  cases,  the  individuals  who  served  as  AEOs  are 
now  senring  as  Software  Executive  Officials  (SEOs). 


A  listing  of  current  DoD  Software  Executive  Officials  (SEOs)  (as  of  June  30, 1992)  is  shown  below.  A 
current  listing  is  available  through  the  AdalC. 


Service/Agency 

Contact 

OSD 

Deputy  Director,  Defense  Research  and  Engineering  (S  &  T) 

OSD 

Director,  Ada  Joint  Program  Office 

U.S.  Army 

Vice  Director  for  Information  Management,  Office  of  the  Director  of  Infor¬ 
mation  Systems  for  Command.  Control,  Communications  and  Computers 
(DISC4/SAIS-2C) 

U.S.  Navy 

Commander,  Naval  Information  Systems  Management  Center 

U.S.  Air  Force 

Deputy  Assistant  Secretary  of  the  Air  Force  (Communication,  Computers  & 
Logistics) 

Joint  Chiefs  of  Staff 

Director,  C4S 

Defense  Information 
Systems  Agency 
(DISA) 

Director,  Center  for  Standards 

Defense  Security 
Assistance  Agency 

Deputy  Chief,  Weapons  Systems  Division  (Plans) 

Strategic  Defense 
Initiative  Organiza¬ 
tion  (SDIO) 

SDIO/SD 

Defense  Advanced 
Research  Projects 
Agency  (DARPA) 

Director,  Software  and  Intelligent  Systems  Technology  Office 

Defense  intelligence 
Agency  (DIA) 

Chief,  DS  Systems  Integration  (DS-SIM) 

Defense  Logistics 
Agency  (DLA) 

Chief,  System  Integration  Division  (Attn:  DLAZI) 

National  Security 
Agency  (NSA) 

Deputy  Director  for  Telecommunications  and  Computer  Senrices  (Technol¬ 
ogy) 

C^l 

Deputy  Director  of  Information  Technology 
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Acronyms 

4GL 

fourth-generation  language 

ABET 

Ada-Based  Environnient  for  Test 

ACEC 

Ada  Conpiler  Evaluation  Capability 

ACM 

Association  for  Computing  Machinery 

ACVC 

Ada  Compiler  Validation  Capability 

Ada 

The  language  (named  for  Ada  Lovelace,  b.  1815) 

ADA 

Americans  with  Disabilities  Act 

AdalC 

Ada  Information  Clearinghouse 

AdaJUG 

Ada  Joint  Users  Group  (formerly  Ada-JOVIAL  Users  Group) 

ADARTS 

Ada-based  Design  Approach  for  Real-Time  Systems  (ADARTS) 

AEO 

Ada  Executive  Official  (see  Software  Executive  Official) 

AES 

Ada  Evaluation  System 

AFMC 

Air  Force  Materiel  Command 

Al 

artificial  intelligence 

AlWG 

Artificial  Intelligence  Working  Group 

AJPO 

Ada  Joint  Program  Office 

AML 

ASEET  Material  Library 

AMO 

ACVC  Maintenance  Organization 

ANSI 

American  National  Standards  Institute 

API 

application  program  interface 

APSE 

Ada  Programming  Support  Environment 

ARG 

Ada  Rapporteur  Group 

ARTEWG 

Ada  Runtime  Environment  Working  Group 

ASEET 

Ada  Software  Engineering  Education  and  Training 

ASIS 

Ada  Semantic  Interface  Specification 

ASSET 

Asset  Source  for  Software  Engineering  Technology 

ATCCS 

Army  Tactical  Command  and  Control  System 

ATLAS 

abbreviated  test  language  for  all  systems 

AVF 

Ada  Validation  Facility 

AVO 

Ada  Validation  Organization 

AVS 

Ada  Validation  Suite 

BBS 

bulletin  board  system 

BIT 

built-in  test 

C’l 

command,  control,  communications,  and  intelligence 

CAI 

computer-assisted  instruction 

CAIS 

Common  APSE  Interface  Set 

CAISWG 

CAIS  Working  Group 
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CASE 

computer-aided  software  engineering 

CAUWG 

Commercial  Ada  Users  Working  Group 

CDR 

critical  design  review 

CIFO 

Catalogue  of  Interface  Features  and  Options 

CIM 

Corporate  Information  Management  (a  DoD  Initiative) 

CM 

configuration  management 

CMM 

Capability  Maturity  Model  for  Software 

CMS 

Code  Management  System 

COCOMO 

Constructive  Cost  Model 

COTS 

commercial  off-the-shelf  [software] 

CRAD 

Contract  Research  and  Development 

CREASE 

Catalog  of  Resources  for  Education  in  Ada  and  Software  Engineering 

CRG 

Character  Rapporteur  Group 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DBMS 

database  management  system 

DEC 

Digital  Equipment  Corporation 

DIA 

Defense  Intelligence  Agency 

DISA 

Defense  Information  Systems  Agency 

DLA 

Defense  Logistics  Agency 

DoD 

Department  of  Defense 

DSN 

Defense  Switched  Network  (formerly  AUTOVON) 

DSP 

digital  signal  processing 

DSSA 

Domain-Specific  Software  Archttectures 

DTIC 

Defense  Technical  Information  Center 

EDWG 

Educational  Products  Working  Group 

Email 

electronic  mail 

EMD 

Engineering  and  Management  Development 

E&V 

Evaluation  and  Validation 

Extra 

Extensions  des  services  Temps  Reels  Ada 

FAA 

Federal  Aviation  Administration 

FIPS 

Federal  Information  Processing  Standard 

FSF 

Free  Software  Foundation 

FTP 

File  Transfer  Protocol 

FY 

fiscal  year 

GKS 

Graphics  Kernel  System 

GPSS 

general  purpose  system  simulation 

GUI 

graphical  user  interface 

HOL 

high-order  language,  high-order  programming  language 

HOOD 

hierarchical  object-oriented  design 
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lEC 

International  Electro-Technical  Commission 

IEEE 

Institute  of  Electrical  and  Electronic  Engineers 

IMSL 

International  Mathematical  and  Statistical  Library 

IR&D 

independent  research  and  development 

IRG 

Information  Systems  Rapporteur  Group 

ISO 

International  Standards  Organization 

MIL-STD 

military  standard 

MIPS 

millions  of  instructions  per  second 

MIS 

management  information  systems 

MMS 

Module  Management  System 

NASA 

National  Aeronautics  and  Space  Administration 

NATO 

North  Atlantic  Treaty  Organization 

NIST 

National  Institute  of  Standards  and  Technology 

NRG 

Numerics  Rapporteur  Group 

NSA 

National  Security  Agency 

NTIS 

National  Technical  Information  Service 

NUMWG 

Numerics  Working  Group 

OBJWG 

Object-Oriented  Working  Group 

OOD 

object-oriented  design,  object-oriented  development 

OOP 

object-oriented  programming 

OORA 

object-oriented  requirements  analysis 

OS 

operating  system 

OSD 

Office  of  the  Secretary  of  Defense 

OSF 

Open  Software  Foundation 

OSI 

open  systems  interconnection 

P3| 

preplanned  product  improvement 

PAMELA 

process  abstraction  method 

PC 

personal  computer 

PDL 

program  design  language 

PDSS 

post-deployment  software  support 

PHIGS 

Programmer's  Hierarchical  Interactive  Graphics  Standard 

PIWG 

Performance  Issues  Working  Group 

POSIX 

Portable  Operating  System  interface 

RAASP 

Reusable  Ada  Avionics  Software  Packages 

RAPID 

Reusable  Ada  Products  for  Information  Systems  Development 

REUSEWG 

Reuse  Working  Group 

RISC 

reduced  instruction  set  computer 

RMA 

rate  monotonic  analysis 

ROM 

read-only  memory 
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RRG 

Real-time  Rapporteur  Group 

SAME 

SQL  Ada  Module  Extensions 

SAMeDL 

SQL  Ada  Module  Description  Language 

sees 

Source  Qode  Oontrol  System 

SDIO 

Strategic  Defense  Initiative  Organization 

SDP 

software  development  plan 

SDS 

strategic  defense  system 

SOSAWQ 

Software  Development  Standards  and  Ada  Working  Group 

SEE 

software  engineering  environment 

SEI 

Software  Engineering  institute 

SEO 

Software  Executive  Official 

SEPG 

Software  Engineering  Process  Group 

SiGAda 

Association  for  Computing  Machinery  Special  Interest  Group  on  Ada 

SLOe 

source  lines  of  code 

SQL 

Structured  Query  Language 

SRG 

SQL  Rapporteur  Group 

SSTDWG 

Secondary  Standards  Working  Group 

STARS 

Software  Technology  for  Adaptable,  Reliable  Systems 

STSe 

Software  Technology  Support  Center 

TQL 

total  quality  leadership 

TQM 

total  quality  management 

UIMS 

user  interface  management  system(s) 

URG 

Uniformity  Rapporteur  Group 

USAF 

United  States  Air  Force 

USN 

United  States  Navy 

UUT 

Unit  Under  Test 

VSR 

Validation  Summary  Report 

XRG 

Ada9X  Rapporteur  Group 
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A VS  100 
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Base  compiler  54, 66 
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Built-in  test  (BIT)  60,115 

C  15.17.81 
C**  15 
C3I  65,104 
CAI  49 

CAIS  Working  Group  95, 1 15 
CAISWG  95,115 
CASE  8,40,51 

Catalog  of  Rasourcas  for  Education  in  Ada  and 
Softwara  Enginaaring  1 5,  50, 1 1 6 
CAUWG  95,116 
COBOL  17,81,82 
COCOMO  18 
Coda  afficiancy  69 
Coda  ganarator  66 
Coda  inspactions  16,31 
Command/oorrtrol  applications  65 
Commarcial  Ada  Usars  Working  Group  95, 1 16 
Commardal  softwara  paekagas  65 
Compila-tima  afficiancy  1 1 , 55, 56, 57 
Compttar  51 
aoquisttion  60 
back  and  66 
banchmarking  57 
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